Comments on: What’s with all the Agile Process Overhead? Part 2 http://www.rallydev.com/agileblog/2009/03/whats-with-all-the-agile-process-overhead-part-2/ Adopt, Scale and Succeed with Agile Development Tue, 10 Jan 2012 03:30:50 +0000 hourly 1 http://wordpress.org/?v=3.0.5 By: Angel http://www.rallydev.com/agileblog/2009/03/whats-with-all-the-agile-process-overhead-part-2/#comment-237 Angel Wed, 04 Mar 2009 00:47:49 +0000 http://www.rallydev.com/agileblog/?p=739#comment-237 >> The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions. I think those interruptions aren't too much agile, thats the kind of stuff that Agile teams try and should avoid. >> The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.

I think those interruptions aren’t too much agile, thats the kind of stuff that Agile teams try and should avoid.

]]> By: Ravi Jha http://www.rallydev.com/agileblog/2009/03/whats-with-all-the-agile-process-overhead-part-2/#comment-233 Ravi Jha Tue, 03 Mar 2009 17:25:14 +0000 http://www.rallydev.com/agileblog/?p=739#comment-233 Jean I love to read your blogs, these are informative and useful. I would like add few more things to this “over head Part2” You are right we should keep some buffers for unknown for what we keep 15% of our capacity (as I written in my last comment, February 27). There are two unknowns we consider a) Known unknowns b) Unknown Unknowns Known Unknowns – The versions of packaged product deployed on different environments are different. You may have different versions deployed on 1. Development environment 2. Testing environment – this is the environment where a different quality center team does test the product’s features, integrity, functionalities and other stuffs. 3. User acceptance (Real user) environment – this may not be the case with every one but this is with us. A small number of users are given access to this environment to test 4. Production environment – this is obvious Now the team is working on , say Iteration 12, and Testing environment has the product delivered on It 10 and in production we have product delivered after Iteration 8. You never know what bugs may appear in what environment, so we keep these as Known Unknowns. To tackle this we already have 15 % buffer and we think that’s enough as when we delivered we did the testing and delivered it with confidence. User may say some thing as bug but most of the time that turns out to be data problem or some thing else. Unknown Unknowns – The name indicates that as a team we are not able to define this. So what we do - we do keep a story some tine 10 hrs some time 20 Hrs in Rally. We do keep two releases in Rally for same Iteration 1. First release is the actual enterprise level release name and number to which our product development is attached with 2. Second release is a maintenance release – Story and support work stories are attached with this release The reason for having two release are 1. Keep track of actual release development with plan estimates, actual hrs spent etc 2. Keep track of maintenance work or support work we do – this helps us to identify issues or risks Now as weeks passes and team members’ uses their time to finish stories and still don’t have any support or maintenance tasks then we bring in other stories from release backlog Some time we have lot of dependencies on other external sources we do know very little when we did our planning and started our iteration. After one or two weeks we do find that the plan we did is not enough then we abort the iteration and plan it afresh. Risk handling We do have our risk register and we do maintain impact analysis and mitigation plan. When we identified risk (initially) and plan the mitigation we did it as one story. As Scrum Master I do keep updating this on regular basis. Jean I love to read your blogs, these are informative and useful. I would like add few more things to this “over head Part2”

You are right we should keep some buffers for unknown for what we keep 15% of our capacity (as I written in my last comment, February 27). There are two unknowns we consider
a) Known unknowns
b) Unknown Unknowns

Known Unknowns – The versions of packaged product deployed on different environments are different. You may have different versions deployed on

1. Development environment
2. Testing environment – this is the environment where a different quality center team does test the product’s features, integrity, functionalities and other stuffs.
3. User acceptance (Real user) environment – this may not be the case with every one but this is with us. A small number of users are given access to this environment to test
4. Production environment – this is obvious

Now the team is working on , say Iteration 12, and Testing environment has the product delivered on It 10 and in production we have product delivered after Iteration 8. You never know what bugs may appear in what environment, so we keep these as Known Unknowns.

To tackle this we already have 15 % buffer and we think that’s enough as when we delivered we did the testing and delivered it with confidence. User may say some thing as bug but most of the time that turns out to be data problem or some thing else.

Unknown Unknowns – The name indicates that as a team we are not able to define this. So what we do – we do keep a story some tine 10 hrs some time 20 Hrs in Rally. We do keep two releases in Rally for same Iteration
1. First release is the actual enterprise level release name and number to which our product development is attached with
2. Second release is a maintenance release – Story and support work stories are attached with this release

The reason for having two release are
1. Keep track of actual release development with plan estimates, actual hrs spent etc
2. Keep track of maintenance work or support work we do – this helps us to identify issues or risks

Now as weeks passes and team members’ uses their time to finish stories and still don’t have any support or maintenance tasks then we bring in other stories from release backlog

Some time we have lot of dependencies on other external sources we do know very little when we did our planning and started our iteration. After one or two weeks we do find that the plan we did is not enough then we abort the iteration and plan it afresh.

Risk handling We do have our risk register and we do maintain impact analysis and mitigation plan. When we identified risk (initially) and plan the mitigation we did it as one story. As Scrum Master I do keep updating this on regular basis.

]]>