There was an error in this gadget

Tuesday, August 10, 2010

On "Command and Control" in Agile Methods

Someone asked - Why does Agile/Scrum suggest Servant Leadership and No Command and Control management....Another person asked recently....Can we really do without command and control in Scrum...
Worse still...someone made a statement...this concept about NO Command and Control in Scrum in B.S...you just can't deliver Software without CONTROL...

Been thinking....are we taking 2 extreme sides here....ultimately came with my theory..here it is..

Ultimately we all know that "Command and Control" is a Time Tested management technique used to "Balance between Constraints".
As Mr Pressman has been teaching us for long, in software development, managers need to balance the iron triangle of Time, Scope and Resource (i.e PEOPLE)...also Quality...but then that's non negotiable :-)

With this context let's relook at any Agile model (Scrum/XP/DSDM) that highlights the principle of NOT using Command and Control (explicit or implicit)...I think there is a "fine print" here...

What Agile/Scrum postulates is NOT to use command and control on PEOPLE...i.e one of the constraints (resources)....at the same time the idea IS to have command and control on the other 2 constraints i.e Scope and Time...

1) The way Scrum/Agile puts command and control on Scope is by ALWAYS having a prioritized Backlog and fixing the Sprint/Iteration Scope at the start of sprints....The PRODUCT OWNER has total command and control on the Backlog and the sprint team commands the scope.
2) The way it puts command and control on Time is by Timeboxing the sprint AND the ceremonies in sprints...The TEAM (PO, SM and Team) has complete Command and control on this Timebox.

SO according to me Agile methods like Scrum/XP etc  (with its emphasis on people) have explicitly taken away the control on people but equally explicitly places a tight control on scope and time....

Friends who believe some control is needed for SW delivery....the answer is simple....by taking away one control completely AND simultaneously putting explicit/total control on the other two, Agile basically empowers the team with more"usable" and "beneficial" control...
Even though most Agile methods are empirical there is definitely some scientific method is this perceived model (methods in the madness!!).
Remember Boyle's Law in Physics (PV=RT)...if we have 3 variables then you cannot control all 3 of them, your best bet is to control (or fix) 2 so that you can allow the 3rd to vary...so obviously you will provide tge freedom to the most important (priceless) component ..PEOPLE...Don't control them ...rather control your other 2 variables...and that's the People Centric Work Paradigm....

So much for now...let me think on this theory to see if there are any chinks :-)

Monday, August 9, 2010

Answering some queries on Agile

I joined a groupsite (AgileBangalore) sometime back...it has been an exciting experience till now....collaborating with fellow Agile enthusiasts, discussing Agile issues/experiences....overtime I have answered a few queries in the groupsite...thought of collating some of those and publishing here..

Question: I am a software tools engineer. How agail and/or scrum helps me to become better tools engineer? (http://agilebangalore.groupsite.com/discussion/topic/show/375323#message_455702)

Ani's Take: Agile is an umbrella term (collection of different names but similar processes based on same principles..e.g: Scrum, XP, DSDM, Crystal, Lean SW Dev etc)....all of them espouse certain human-centered management processes/framework...some of them (like XP) go further and suggest Engineering Best Practices to adopt (e.g: Unit Testing and TDD, Continous Integration/Build and Config Mgmt, Automated Testing etc)...
Nearly all Agile practices will need some or all of these practices to succeed and these will in turn demand skilled artisans/craftsmen to implement via tools....so if you joined the Agile revolution to enhance your ability in this direction, your best bet will be to investigate these...(try googling "software craftsmanship" and you'll get lot of starters)...
However I want to give a caveat....Agile DOESNOT espouse Tools and Automation for any human-centered interactions (you can still use them but in my experience they are rightly used only by mature teams).....
So if your idea of using tools is to get status updates I would not support that since by doing so you are going to sap the spirit of the daily scrum...your best tools to manage these would be whiteboards, excel files (and for mature teams some lightweight manegement tools like VersionOne, RallyDev, Mingle etc.
Lastly, you can still use some tools to capture metrics ...follow the same rule...try and focus metrics on the work and not the people....so you can use tools for code review, defect management, static code analysis...all these will enable better agile team spirit...don't focus on tools to captures things like - the time taken to complere stories (unless mandated by mgmt), variance in productivity between team members etc etc..


Question: Generally people believe that Agile doesn't require documentation or doenn't support documentation. How much documentation do you use in your agile projects? What has worked well for you, and what hasn't? (http://agilebangalore.groupsite.com/discussion/topic/show/306245)

Ani's Take: There are 2 types to documentation (and the Agile principle is minimal but sufficient documentations)
1) Documents supporting delivery to external customers (this can be Release notes, User guides, Admin guides etc)....I don't think there is any scope of reducing this type of documentation

2) Documentation supporting internal delivery - e.g: Status Reports, Meeting Minutes, Specification documents (Use Cases Diagram, Functional Specs, Tech Specs etc etc)...again sometime a few of these are mandated (in service companies, clients may ask for this before transition to support)...

However the Agile principle should be to question the need and detail needed for each and take the minimum but sufficient approach...e.g: If client wants a Use Case diagram before the transition, I will take the following approach...thruout dev cycle I will NOT manage any document but rely on .MDL files to manage by user cases, classes, sequence diagrams etc and in the last sprint keep a story item to create a use case diagram....by that time the components of the mdl file would be stable and it would be easy to create the document (in fact tools like Rational Rose may just create it for you)...Similarly I will NOT waste time on multiple status reports (no reports of scrum meetings etc), however make sure the team is capturing the relevant and important "conversations" in some sort of documents...

Bottom line....Agile is not for NO documentation it's for any documentation that has a purpose AND the simplest way to deliver those...


Question: As per your experience provide the details of key challanges you faced at your organization/project etc? (http://agilebangalore.groupsite.com/discussion/topic/show/303844)

Ani's Take: IMHO challenges in Agile Adoption can be at three levels


1) Higher Management Level challenges
i) If Agile was thought of as a silver bullet that will fix all issues, it causes problems since Agile on the other hand has a great knack of bringing forth the hiddne orgnanization issues (e.g: manager's tendency to command and control, no preparedness in Test Automation)
ii) Agile needs cross functional collaboaration which sometimes can open a can of worms in a strictly Functional Org (Mgmt needs to subscribe to matrix organizations)
iii) Management dictats (need metrics from teams, need to compare productivity from diff teams etc) can be misinterpreted by teams or can be mis-directional to Agile principles.

2) Mid Management Level (level of Functional managers who are assigned to drive Agile Adoption)
i) Not understanding the essence of Agile may lead to modifying Agile wrongly (What we call as Scrumbuts)...e.g: Functional managers tend to attend Scrum meetings and it ends up being status meeting AND team stop talking between themselves since now they are escalating issues to respective managers and they are discussing issues at their level...
ii) Not having or consulting Agile Coaches leads to combining Agile with Waterfall practices (e.g: Let's use Sprints 1 and 2 for Designing only)...We popularly hear terms like Scrummerfall (Try googling to get case studies...have seen in my experience too)
iii) This layer feels insecure (specially when there are no coaches OR senior mgmt is not clear in communicating) about their diminished role in day to day activities (loss of command) and hence resist Agile adoption using hidden or clear obstacles.

3) Team level
i) I have seen that teams are normally the least part of the problem....IF they are properly guided by a strong ScrumMaster/Coach in the initial part of agile (Guidance is not just theory...but providing the RIGHT hands on advice as an when needed)...however sometimes teams face issues in understanding "self - organization" and tend to depend on managers for decision making
ii) In few cases (not many) I have seen some team members who have come from successful Waterfall/Iterative implementations, resist Agile (too fast, too risky, too pressure).....acc to me these were symptoms of other problems (most probably they were insecure in some way, or may be didn't understand the tenets of Agile clearly).
iii) Product Owners - Unfortunately the spread of scrum has produced very good ScrumMasters (training, guidance etc)....but there are not many mature product owners (simply because there are not enough mentors, guidance or training for them)...I believe POs are the most complex role (they face the maximum change in work process) and hence if not guided or trained they will not succeed and put the teams at risk
iv) SMs - There are lot of SMs but not many who really can mentor the team, push back on outside interference AND be a true "servant leader"....SMs tend to become PMs (unfortunately due to environments or lack of coaching).


So much for now....will add some queries and my 2 cents on them later...ciao




Sunday, April 25, 2010

Stay Hungry, Stay foolish - Steve Jobs

HERE IS A SPEECH DELIVERED BY STEVE JOBS...The Best I have heard from a Leader...EVER (and that's a toll Order)



I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life.


That's it. No big deal.
Just three stories.

The first story is about connecting the dots. I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out? It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.

And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.

It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢ deposits to buy food with. And I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on.

Let me give you one example:

Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating. None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them.
If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later. Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

My second story is about love and loss.

I was lucky - I found what I loved to do early in life. Woz and I started Apple in my parent’s garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation - the Macintosh - a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out.When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.

I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.

I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.

During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I retuned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.
I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was a awful tasting medicine, but I guess the patient needed it.

Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.

My third story is about death.

When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.

Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.

I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now. This was the closest I've been to facing death, and I hope its the closest I get for a few more decades.

Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:

No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true. Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma - which is living with the results of other people's thinking. Don't let the noise of other's opinions drown out your own inner voice.

And most important - have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.

Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish."

It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.


Stay Hungry. Stay Foolish.

Thank you all very much.

Saturday, April 24, 2010

The Art of Appraisal

Big Boss: This year your performance was good, excellent and outstanding. So, your rating is "average".

Kumar: What? How come 'average'?

Big Boss: Because...err...uhh...you lack domain knowledge.

Kumar: But last year you said I am a domain expert and you put me in this project as a domain consultant.

Big Boss: Oh is it? Well, in that case, I think your domain knowledge has eroded this year.

Kumar: What???

Big Boss: Yes, I didn't see you sharing knowledge on Purchasing domain.

Kumar: Why would I? Because I am not in Purchasing, I am in Manufacturing.

Big Boss: This is what I don't like about you. You give excuse for everything.

Kumar: Huh? *Confused*

Big Boss: Next, you need to improve your communication skills.

Kumar: Like what? I am the one who trained the team on "Business Communication", you sat in the audience and took notes, you remember?

Big Boss: Oh is it? Errr...well..I mean, you need to improve your Social Pragmatic Affirmative Communication.

Kumar: Huh? What the hell is that? *Confused*

Big Boss: See! That's why you need to learn about it.

Kumar: *head spinning*

Big Boss: Next, you need to sharpen your recruiting skills. All the guys you recruited left within 2 months.

Kumar: Well, not my mistake. You told them you will sit beside them and review their code, and most resigned the next day itself. Couple of them even attempted suicide.

Big Boss:*stunned* (recovers from shock) Err...anyway, I tried to give you a better rating, but our Normalization process gave you only 'average'.

Kumar: Last year that process gave me 'excellent'. This year just 'average'? Why is this process pushing me up and down every year?

Boss: That's a complicated process. You don't want to hear.

Kumar: I'll try to understand. Go ahead.

Big Boss: Well, we gather in a large room, write down the names of sub-ordinates in bits of paper, and throw them up in the air. Whichever lands on the floor gets 'average', whichever lands on table gets 'good', whichever we manage to catch gets 'excellent' and whichever gets stuck toceiling gets 'outstanding'.

Kumar: (eyes popping out) What? Ridiculous! So who gets 'poor' rating?

Big Boss: Those are the ones we forget to write down.

Kumar: What the hell! And how can paper bits stick to ceiling for 'outstanding'?

Big Boss: Oh no, now you have started questioning our 20 year old organizational process!

Kumar: *faints*