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