wording changes about playbook

[frankhmcnally]

Good notes. Agree particularly with the comment about role distinction between product owner and project manager. Ideally, the product owner has functional decision making authority, and would provide direction to the project manager & resolve any questions about functionality to be delivered against the product vision.

[rdymond1]

-1 to Change 1-4 weeks to 1-8 weeks for iteration cycles globally
I can't think of any Agile writing where 8 weeks is advocated for an iteration. 4 weeks is the maximum, and the most popular iteration lengths are 2 or 3 weeks.
-1 to "There may be a large support team of people that are used occasionally or for support requirements." This is an anti-pattern for Agile. It creates dysfunctional teams, since the "large support team of people" can't be counted on to meet the needs of the sprint goal since they are multi-tasking on other things. They are also not a team.

[simplydan]

Good notes

+1 to change 1-4 eeks to 1-8 weeks for iteration cycles. To answer rdymond1, one Agile writing that describes preference for shorter timeframe but leaves door open for 8 week iteration is the "Principles Behind the Agile Manifesto"

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

http://agilemanifesto.org/principles.html

[rdymond1]

My understanding is "Deliver working tested software" in this context means to your customers or to production. In the 12 years I have been delivering projects using Agile, I have not seen a team use 8 weeks for iterations. As a certified trainer with the Scrum Alliance, I can confidently say that there is no support within Scrum for 8 week iterations. Neither is there support in Extreme Programming (XP) for 2 months. XP recommends 1 or 2 weeks.

From the Core Scrum definition in the Agile Atlas:
http://agileatlas.org/atlas/scrum#values
"The Development Team builds the product incrementally, in a series of short time periods called Sprints. A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals."
The large majority of Agile implementations use Scrum. http://stateofagile.versionone.com/
So these definitions should not be different from currently accepted practice. The people referring to these documents are not experts, so let's not put in practices that are not recommended. 8 weeks creates mini waterfalls, is hard for the team to plan, suffers from student syndrome, lowers quality due to the crunch on testing at the end, and only allows for 6 iterations per year, significantly reducing the core principle of Agile, Lean, and Scrum: learning and continuous improvement.

[simplydan]

rdymond1: I'd never seen 8 week iterations either, and would not support them for the same reasons you've described. Understand and agree with explanation above. I reacted too quickly to the "nowhere in Agile writing..." element of the comment.

[clecknerj]

One thing we want to be very careful about is differentiating agile and Scrum characteristics in the playbook.  In my training as a PMI Agile Certified Practioner we were told iterations are 1 week to 2 months in length with a preference for the shorter time period.
Until Federal contracts contain only agile-process-compatible clauses and oversight personnel drop the Waterfall mentality, it is highly likely a support team will be required.  This is my observation after working on 325 IT projects with more than half using agile processes. (My first agile project was in 1979 but the term agile process didn’t exist then. We called the process “Not Waterfall.”) Another reason a support team may be necessary is the Federal government divides responsibility among multiple contractors.  If your team has overall responsibility for the full life cycle including operations, you have to use those other contractors for their areas of responsibility.
Whether a support team is an anti-agile pattern depends on the situation. If the support team enhances the core team’s ability to deliver working software by offloading non-core tasks, then the support team is an agile pattern for that situation.  Examples of non-core tasks that could be offloaded are project management, training, IV&V, deployment to production, low value documentation (shelfware), help desk levels I&II, sponsoring, communications, data cleaning, policy interpretation, creating security paperwork for Authority to Operate, database administration, hardware and network operations,…  These tasks are important to implementing a system but are not core tasks for creating working software and deploying it to a user-accessible environment, e.g. test environment.  This is especially true if the Federal agency has a separate contractor that controls deployment to production. (Recall an agile team gets credit for completed user stories even if the customer decides not to release the software to production).
 
 

-------- Original Message --------Subject: Re: [playbook] wording changes (#41)From: Robin Dymond [email protected]: Thu, August 21, 2014 11:16 pmTo: WhiteHouse/playbook [email protected]: clecknerj [email protected] understanding is "Deliver working tested software" in this context means to your customers or to production. In the 12 years I have been delivering projects using Agile, I have not seen a team use 8 weeks. As a certified trainer with the Scrum Alliance, I can confidently say that there is no support within Scrum for 8 week iterations.
From the Core Scrum definition in the Agile Atlas:http://agileatlas.org/atlas/scrum#values"The Development Team builds the product incrementally, in a series of short time periods called Sprints. A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals."The large majority of Agile implementations use Scrum. http://stateofagile.versionone.com/So these definitions should not be different from currently accepted practice. The people referring to these documents are not experts, so let's not put in practices that are not recommended.
—Reply to this email directly or view it on GitHub.