Joint KC Agile and KC IIBA meeting

[Tom Miller]

I attended the join KC Agile and KC IIBA meeting.  I was impressed by the patience of the Agile people for what was a very high over-view of Agile to a mix-bag of Business Analysts.  I am confident that what was presented was pretty elementary if you have been attending KC Agile meetings for a while.

I am also pleased that I think I actually understood what the presenter was saying.  What I missed from previous exposure to Agile and to Scrum was how important fully automated testing was to support doing Agile.

I had finally understood that Scrum doesn't address the Agile programming practices that go on inside the developer team less than 3 weeks ago :(

Tom Miller

 

#-#-#-#
"You are entitled to your own opinion but not to your own facts."  NPR's Science Friday 2 March 2012, first hour.
----
"If I have seen a little further it is by standing on the shoulders of Giant" software.
paraphrased from Issac Newton.
-------------------------------------------------------------------------------------------------------------------
Aspiring Business Analyst, Business Consultant and COMPUTER HELP (including IT troubleshooting, website creation/hosting and customizing Access databases for small business) and sometime truck driver.  Capm, Mcp, A+, MOS, Master Certification in Customer Requirements Analysis, Project Management & Internet Fundamentals - http://www.Galensoncaa.com - http://tech.groups.yahoo.com/group/sylvania_smartbook/ - http://www.ChatNFiles.com

[Martin Olson]

Thanks for the kind words Tom.  I enjoyed the session too..  

I'm not sure I understand the sentence " I had finally understood that Scrum doesn't address the Agile programming practices that go on inside the developer team less than 3 weeks ago :( "  and hope I didn't lead you astray.  Can you elaborate?

Thanks,

martin

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
________________________________________
Martin Olson | mol...@siliconprairesolutions.com| Phone 913.620.4870

[Raghu Kundurthi]

Honestly, Agile/SCRUM are primarily geared to address IT engagements that have a a predefined/determined shelf life period  of 3-4 weeks.

• You setup a Planning Session (notice the singular!) at the beggining of the Month.
• 
  
• You identify all the Business Requirements that require to be addressed and resolved prior to the Planning Session.
• 
  
• You define the User Story relating them to the Business Requirements .
• 
  
• You shortlist all such User Stories that you prioritize to address for that month in the monthly  planning session.
• 
  
• You take a consensus from each SME on the User Story to derive a high level estimate.Most of the Sprints are of 4 weeks in durations .

• The focus is on targeting to complete the User  Story identified in the Planning Session  within the Sprint.

• Each USer Story will have tasks/sub tasks defined at a grain that would tie in to the SDLC effort required.

• The Daily Huddles with a consistent  focus on three areas and not last beyond 30 minutes
  
•  - Task worked on for that day
• Impediments/SHow Stoppers
• Next Steps
• Ensure the SMEs/leads /individualcontributors update the hours burnt that would be reflected in  the burn down charts.
• Ensure the SCRUM master keeps a tab on the progress/velocity(direction sense indicating progress/regress on a user story).

Hope this brief 101 overview helps .....

On Fri, Mar 16, 2012 at 6:56 AM, Tom Miller <tlgal...@yahoo.com> wrote:

--

You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
Raghu Kundurthi

[James Peckham]

Hello,

This is great let's have a dialogue here, there are some things here that I have to comment on because from my perspective of agile, scrum, and XP practices like User stories: I believe these points written here are misleading and not entirely valid in Agile. Even the opening statement has a hint of specific and declarative information that may be true in some observational way on projects you have experienced but is not the over all feel and purpose of Agile/Scrum.

First let's remind everyone that Agile is a set of values. It's not a methodology. There is no list of steps or rules in "Agile". Scrum is a set of project management rules that combined create a process control framework that you can wrap around your methodologies to systematically inspect and adapt them and the product you're creating with them. Extreme Programming (XP) is a set of engineering practices that have a proven track record in the field and are cranked up to "11" to be ultra beneficial and then further proven that they do have synergies. 

User stories is a subset of Extreme Programming.

Extreme Programming can be used within Scrum - As can standard requirements processes, but let's put that aside for a moment.

Agile is a set of governing values that we will look at during reflection of our inspect and adapt cycles within the scrum framework.

Now, let's go through your statements.

 

" Honestly, Agile/SCRUM are primarily geared to address IT engagements that have a a predefined/determined shelf life period  of 3-4 weeks. "

This is very declarative and many industries are reaping benefits of agility by using scrum on projects that are Evergreen projects or other long term (1-2 year projects). The great thing about Scrum is that it just wraps your product and process and gives you an inspect and adapt cycle. If you can squeeze more profits out of the project then it is sustainable for infinite periods of time. Our organization is actually running ongoing scrum cycles for all product lines and we never stop sprinting. It is the job of product owners to continually fill the pipeline with engagements (using your terminology).

 

You identify all the Business Requirements that require to be addressed and resolved prior to the Planning Session. 

You are making an assumption here. You believe you can identify "All" business requirements at all prior to testing the market with real working software. This is untrue. Can you write the perfect opus or term paper without peer review? Software development and user stories is the same way. You cannot create a requirements document that captures all requirements perfectly before beginning development. Incremental development and User Stories accepts this fact and moves beyond it by providing pivot points at the end of a sprint to revisit the user stories in the backlog or create new ones or cancel the project if the goals are met or invalid.

You define the User Story relating them to the Business Requirements . 

The user story represents a conversation with the real people who need the solution if possible. If not, a proxy to those people (Product owner as it is called, this may be a Business analyst for some). The idea of "Business Requirement" no longer exists because to say it is required is not necessarily true. Some people have started calling them "Desirements" but the fundamental concept that is needed to understand agility is that we need only understand who the user is and why they need a solution and what the proposed solution may be and then the value in which they think it will make them. Some user stories will fall off for not being very valuable. Others will fall off because they are later deemed unccessary, some will fall off because there just isn't enough budget to do them. What remains is the most valuable stories int he backlog worked in order of their value. The term Business Requirements is dead and useless on an agile project because it causes dysfunction via confusion to stakeholders who end up believing that it will be in the system.

You shortlist all such User Stories that you prioritize to address for that month in the monthly  planning session. 

Sure, you could do it in this way, however your planning session will be very long if you spend it prioritizing. Traditionally prioritization happens out of band from the Sprint planning meeting. You can do it adhoc/on demand every time a new story enters the system or you can do it at some interval or cadence (we do it weekly for 1 hour). Also, I prefer to call it "Ordering" because it gets rid of dysfunctional fighting and how some things are of equal priority. Everything needs ordered in a stacked list. You cannot have 2 things of equal ordering... but you can have them equal priority.

You take a consensus from each SME on the User Story to derive a high level estimate.Most of the Sprints are of 4 weeks in durations . 

sprints are by definition of scrum no longer than 30 days. They can be as short as 3 days in my opinion but the shorter they are the more overhead you pay in planning and retrospection.

The focus is on targeting to complete the User  Story identified in the Planning Session  within the Sprint. 

Nit pick here but you focus on completing multiple user stories per sprint. if you only have 1 story that is an extreme risk to the sprint. The story is most likely either too large or the team has significant problems delivering if they cannot do more than 1 story in a sprint.

 Each USer Story will have tasks/sub tasks defined at a grain that would tie in to the SDLC effort required.

yep, some additional info. Tasks in agile usually feel different than tasks in other projects i've worked on. Usually a task communicates 1 day or less worth of commitment to the team. Often times a bad task is written like "Test the user story" where the real tasks should be broken down into small tangible commitments "Execute the test for happy path", "Execute the test for boundry cases on text box", "Execute performance test for data load", "Do a day worth of exploratory testing"

• The Daily Huddles with a consistent  focus on three areas and not last beyond 30 minutes 

•  - Task worked on for that day

• Impediments/SHow Stoppers

• Next Steps

That's not a bad way to look at it. the template from scrum is a 15 min or less meeting preferably closer to 5 minutes and cover these 3 questions for each team member: What tasks did i do since last scrum? What task Will i do before next scrum? what things are in my way of completing my current task? It is a subtle difference but i can promise you it is VERY important to honor this difference. Use this template and then expand from there as needed. Also this meeting should invite all stakeholders as chickens and be in the same place always. and ONLY the team members can talk (Pigs). See more about chickens and pigs on the internet.

 

Ensure the SMEs/leads /individualcontributors update the hours burnt that would be reflected in  the burn down charts. 

Yes, before daily scrum (daily huddle). Usually at the end of the business day since you can more easily remember what you did.

Ensure the SCRUM master keeps a tab on the progress/velocity(direction sense indicating progress/regress on a user story). 

Sorry i just disagree with this. ScrumMaster should teach the values and goals as I have done in this email and make sure the team is healthy, uninhibited by the organization, and promote teamwork while providing visibility to progress to the organization through the metrics of the burn down chart and release burn up chart as mentioned by Martin.

I hope this has been helpful and I must say thank you for pointing out these topics!!!

Regards, James 

James Peckham CSP, CAPM

Engineering Project Manager
Perceptive Software

James....@perceptivesoftware.com
www.perceptivesoftware.com

+1 913 422 7525 corporate
+1 913 667 6182 direct
+1 913 219 1433 mobile

Stay connected with us.       

Inspire: The Perceptive Software User Conference
www.perceptivesoftware.com/inspire

NOTICE: If received in error, please destroy the message and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

[Tom Miller]

Martin,

Prior your presentation last night I have been "studying" Agile and Scrum.  In a video I ran into the distinction that Scrum is a project management methodology and what Agile techniques the team used to solve/design/code/text (opps, TEST) the solution after they had the requirements was actually a different part of the Agile toolbox.  eg. eXterme Programming, Shared coding, Kaiban(?), etc. 

I mentioned that because it was important to me in my understanding of Agile and of Scrum rather than because it came up last night.  Sorry for being less than clear.

Tom Miller

 

#-#-#-#
"You are entitled to your own opinion but not to your own facts."  NPR's Science Friday 2 March 2012, first hour.
----
"If I have seen a little further it is by standing on the shoulders of Giant" software.
paraphrased from Issac Newton.
-------------------------------------------------------------------------------------------------------------------

Aspiring Business Analyst, Business Consultant and COMPUTER HELP (including IT troubleshooting, website creation/hosting and customizing MS Access-based Applications) and sometime truck driver.  Certifications: CAPM, MCP, MOS & A+, Master Certification in Customer Requirements Analysis, Project Management & Internet Fundamentals from Brainbench.com - http://www.Galensoncaa.com - http://tech.groups.yahoo.com/group/sylvania_smartbook/ - http://www.ChatNFiles.com

---

From: Martin Olson <mols...@gmail.com>
To: kc_a...@googlegroups.com
Sent: Friday, March 16, 2012 8:42 AM
Subject: Re: Joint KC Agile and KC IIBA meeting

Thanks for the kind words Tom.  I enjoyed the session too..  

I'm not sure I understand the sentence " I had finally understood that Scrum doesn't address the Agile programming practices that go on inside the developer team less than 3 weeks ago :( "  and hope I didn't lead you astray.  Can you elaborate?

Thanks,

martin

On Fri, Mar 16, 2012 at 6:56 AM, Tom Miller <tlgal...@yahoo.com> wrote:

I attended the join KC Agile and KC IIBA meeting.  I was impressed by the patience of the Agile people for what was a very high over-view of Agile to a mix-bag of Business Analysts.  I am confident that what was presented was pretty elementary if you have been attending KC Agile meetings for a while.

I am also pleased that I think I actually understood what the presenter was saying.  What I missed from previous exposure to Agile and to Scrum was how important fully automated testing was to support doing Agile.

I had finally understood that Scrum doesn't address the Agile programming practices that go on inside the developer team less than 3 weeks ago :(

Tom Miller

 

#-#-#-#
"You are entitled to your own opinion but not to your own facts."  NPR's Science Friday 2 March 2012, first hour.
----
"If I have seen a little further it is by standing on the shoulders of Giant" software.
paraphrased from Issac Newton.
-------------------------------------------------------------------------------------------------------------------

Aspiring Business Analyst, Business Consultant and COMPUTER HELP (including IT troubleshooting, website creation/hosting and customizing Access databases for small business) and sometime truck driver.  Capm, Mcp, A+, MOS, Master Certification in Customer Requirements Analysis, Project Management & Internet Fundamentals - http://www.galensoncaa.com - http://tech.groups.yahoo.com/group/sylvania_smartbook/ - http://www.ChatNFiles.com

--
You received this message because you are subscribed to the Google Groups "AgileKC" group.
To post to this group, send email to KC_A...@googlegroups.com.
To unsubscribe from this group, send email to KC_Agile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/KC_Agile?hl=en.

--
________________________________________
Martin Olson | mol...@siliconprairesolutions.com| Phone 913.620.4870