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
No comments:
Post a Comment