[email protected], attributed copies permitted 1 generic agile collaborative development (acd)...

[email protected], attributed copies permitted 1

Generic Agile Collaborative Development (ACD) Processfor Working Group Project Management

Motivated for and by usage in the Agile Systems Engineering Working Group

(completed project paper: www.parshift.com/s/140630IS14-AgileSystemsEngineering-Part1&2.pdf)

INCOSE Agile Systems and Systems Engineering WGRick Dove

Spring 2013

Work in process:Material for an IW16 presentationMaterial for an IS16 paper

http://www.parshift.com/s/140630IS14-AgileSystemsEngineering-Part1&2.pdf


UURVE for ACD

Speed is important as the topic is timely: SEBoK needs a solid reference ASAP, WG projects need compatible foundation and bounds. Process fundamentals not clear as yet. Process has entrenched Software Development framework and practice beliefs beyond fundamentals.Is this a three release only project (Yes for now) – or something that will live and evolve?

Agile systems have effective situational response under: Unpredictability: unknowable situations Uncertainty: randomness with unknowable probabilities Risk: randomness with knowable probabilities Variation: knowable variables and variance range Evolution: gradual (relatively) successive developments

What does the process do? Develops written modules of key-point fundamentals for assembly with variation appropriate for different users and purposes, with: uncertain participant constituency and nature of participation uncertain customer requirements and requirements evolution uncertain reviewer reception uncertain test-driven methods uncertain body-of-knowledge (BOK) references to recognize and relate to uncertain tools for modular data-base and release-assembly unpredictable reception among entrenched Agile SW development community unpredictable maintenance and support needs unpredictable discovery of new and necessary fundamentals risk: irreconcilable BOK contradicting thought variation in audience/customer needs variation in writer-time available for development evolution of the working group constituency and culture over time


Responsiveto Change

EffectiveDistributed

Collaboration

Self-Motivated

Participation

Recognizeand

CelebrateProgress

Supportwith

CollaborationTools

Pairingand

Swarming

Managewith

DisciplinedProcess

RapidDeliverable

Convergence

Transparencyof Decisions& Progress

FluidPO/SMRoles

Describe/Select

MeaningfulProjects

HighQualityINCOSE

Deliverable

IterateShort InterimDeliverablesTest-Driven

CustomerV&VRefactor

Goals, Tests,WIP, Process

ConOps: Agile Collaborative Development

Goals/ObjectivesEnabling Activities


Fundamentals Project – Agile Collaborative Development

Proactive Response Issues:• Create tasks and completion (test) criteria• Create sprints and completion (test) criteria• Create R3 V&V event/process/team – and R3 completion (test) criteria• Create R3 INCOSE deliverable (INCOSE packaging requirements)• Create ease of tool learning and use• Improve task completion rate and completion quality• Improve employed process effectiveness• Migrate to perpetual updated-release capability• Modify goals, sprints, tasks, tests, tools, process (refactoring)• Modify task team expertise

Reactive Response Issues• Correct team dysfunction, blockage, tasks not chosen• Correct PO and SM mismatch with project and tasks• Correct ineffective tools, and user difficulties with tool use • Correct process architecture problems (infrastructure and modules)• Variation in team-member schedule availability and team-member time• Variation in PO and SM schedule availability and time• Expand number of manageable parallel tasks• Expand number of team members per release• Reconfigure task-team membership• Reconfigure designated PO and SM on releases, sprints, and tasks• Reconfigure task-team for swarming on blockage

Each release is a project that can build upon and augment prior release materialR1 develops initial modules, and may develop some variations of these modules (need data-base)


Activities – Process StepsSuggested Guidelines for Process Steps in the Activities

• Describe/Select Meaningful Projects

Need and intent: WG projects must fit the charter and produce results meaningful to INCOSE.1. Project interest catalyses a self-organized candidate-project team.2. Project-leadership is self-identified and is responsible for the development of a candidate-

project description.3. Project leadership submits the candidate-project description to the WG leadership (chair

and co-chairs).4. WG leadership is responsible for the evaluation of the project description, based on

completeness of description criteria and fitness to the WG charter. 5. The WG chair is responsible for transmitting, within one week, evaluation results to

candidate-project leadership, and designating transition to project-in-process status or suggesting corrective measures if appropriate.

• Test-Driven Customer V&V

Need and intent: Rapid and verbal (not written) test feedback to the entire development team, to sustain development momentum and to allow Q&A for full understanding by all team members.1. V&V task teams consist of customers identified in the project description, and others as

appropriate.2. Tests for project final deliverables are defined by the V&V team.3. Tests for incremental deliverables are defined by the development team, guided by the final

V&V test definition.4. An incremental-deliverable test begins when the development team passes results to the

test team. Incremental deliverables are evaluated according to the test definition, and accomplished by opt-in test-team participants from the project team and customer(s) as desired. The test-team chooses a test-results communicator to provide finalized test results, verbally for Q&A, to the development team, all within one week.

5. A final V&V test begins when the development team feels the final project results are deliverable (at least in first-pass final-deliverable intent). V&V test process, time duration, and results communication (done verbally for Q&A) is the responsibility of the V&V team.


Activities – Process Steps• Self-Motivated Participation

Need and intent: Project velocity and quality are accelerated when performed by empowered people with a personal interest in and/or need for the results.1. Team members choose individually what they wish to work on, and when.2. Choices are selected from task stories on a team-wide accessible kanban board (or

equivalent), and advanced through the stages of: story writing, to-do, in-progress, verify, and done.

3. Story stage: Stories may be created by any team member, guided by the project description.

4. To-do stage: The advance from story stage to to-do stage should not occur until any precursor needs are satisfied, and the advancement should be done by the scrum master. The scrum master is responsible for removing stories that are redundant, overlapping, or inappropriate – if the story originator hasn’t done so.

5. In-process stage: The advance from to-do to in-progress is done by opt-in individuals as and when they wish, with encouragement and recruitment from the scrum master for unsubscribed tasks in need of attention. Tasks should have at least two team members (pairing) involved.

6. Verify stage: The advance from in-progress to verify is done by any one of the task-team members with agreement from the task team. Verification should be completed within one week from the time that the task enters the verify stage. Test-team members opt in, with at least two team members if the test can not be conducted with unequivocal pass-fail objectivity. Tasks that don’t pass the test are returned to the to-do stage by any member of the test team with team agreement.

7. Done stage: The advance from verify to done is accomplished by a member of the opt-in test-team when results pass the test as agreed by the test team.


Activities – Process Steps• Manage with Disciplined Process

Need and intent: volunteer project participants may be remotely located and asynchronously active, and may enter and depart from projects-in-process activity. A clear and current operating procedure should be easily accessible to all at any time. 1. A project will be managed by a disciplined and documented process. The documented

process and project-progress will be available to all team members, and publically available to (authorized if necessary) project observers.

2. Development of the project management-process and subsequent management of the process is the responsibility of the current PO and SM.

3. A project cannot start until a (at least preliminary) management process is documented, which may be refactored as the project progresses. A process may start with a WG “standard” process management discipline.

• Support with (Free) Collaboration ToolsNeed and intent: Volunteers are committing their time for development, which should be supported with productivity tools that are easy to learn and access, and do not insert a personal expense barrier.1. Transparent asynchronous-access to work-in-process, and project progress.

Candidate: at http://scrumy.com. 2. Audio meetings – for synchronized decision making and team meetings.

Candidate: at www.freeconferencecall.com.3. Screen meetings – for synchronized team meetings. Candidates: INCOSE Live Meeting

or Google Hangouts at www.google.com/+/learnmore/hangouts. 4. Shared storage – Candidate: INCOSE Share Point site or Google Drive at

https://drive.google.com/?pli=1#my-drive.5. Wiki – to support collaborative thought and document development.

Candidate: (new WG web-site).

http://scrumy.com/

http://www.freeconferencecall.com/

http://www.google.com/+/learnmore/hangouts

https://drive.google.com/?pli=1


Activities – Process Steps• Iterate Short Interim Deliverables

Need and intent: Incremental deliverables provide early feedback to developers and limit work-sprint to acceptable volunteer commitment. 1. PO in collaboration with team selects tasks in backlog for a given sprint, and

establishes sprint duration.2. Tasks are tested for completion by the team.3. Sprint results as tested for

• Pairing and SwarmingNeed and intent: Pairing – reduce need for process training and documentation as one with experience informs the other; increase task quality with collaborative thinking. Swarming – maintain velocity by bringing many minds to bear immediately when a task-team gets stuck. 1. Project tasks have a minimum of two collaborating participants, preferably

one at least is experienced or knowledgeable in the project process and tools.

2. When task participants are stuck, additional project personnel become aware in stand-up meetings or are informed by the SM, and assist in removing the task blockage. The SM is responsible for detecting task blockage and providing or finding necessary assistance if other project personnel are slow to assist.


Activities – Process Steps• Transparency of Decisions and Progress

Need and intent: Improve quality of decision making with early full team impact-feedback and concurrence; improve task velocity and quality with early identification of slippage, blockage, and cross-team dependency issues.1. Frequent stand-up (equivalent) meetings, to reveal progress status and

issues.2. PO and SM burndown monitoring and plan adjustment as required.

• Fluid PO/SM RolesNeed and intent: PO and SM personnel may have participation-time interrupted, and/or my find project-plan refactoring results or specific iterations/tasks are better handled by others more knowledgeable. 1. PO and SM roles may change fluidly during a project, as appropriate for

having the most qualified and productive persons in those roles at any time. 2. The PO role: Outward facing creator/conveyor of project context, values, and

vision; team facing task and backlog prioritization decision responsibility. 3. The SM role: Team facing process steward and productivity facilitation.

• Refactor Tests, Task WIP, ProcessNeed and intent: Quality is paramount, project progress reveals new understandings that should be refactored as changes into anything that can be improved. 1. Technical-debt attention is recognized and valued as important backlog

tasks.


• Recognize and Celebrate ProgressNeed and intent: High team moral is known to improve project velocity and quality, so efforts should be made keep morale high. 1. A task that is completed should include the names of all who contributed.2. The entire project team should be notified by project leadership when a task

is completed, with all contributors named.3. The final project deliverable will recognize all contributors alphabetically by

name, as co-developers. Project leadership may be recognized specifically, as project leadership deems appropriate.

4. Completed projects of appropriate nature will be submitted by project leadership, with concurrence of the working group leadership, to INCOSE, for consideration as INCOSE Product or Technical Data.

5. Contributors to progress on projects will be recognized by name at the IW and IS workshops, and in the semi-annual WG progress reports made to Tech Ops by WG leadership.

6. The project POs and SMs are responsible for team morale.

Activities – Process Steps


Agile Collaborative Development – WG Umbrella Process

Proactive Response Issues:• Create project descriptions• Create project plans (Sprint Zeros)• Improve overall process effectiveness• Improve INCOSE deliverable completion rate and quality • Migrate to new types of project deliverables• Migrate the process to other WG needs• Modify tool modules available for use and acceptable to security issues• Modify modules available for different project type needs

Reactive Response Issues• Correct process deficiencies • Correct projects unsubscribed• Correct ineffective tools and user difficulties with tool use • Correct process architecture problems• Variation in project types• Variation in time constraints to project completion• Expand number of projects manageable by the WG• Reconfigure modules needed for a given project


On Why Agile Methods Work (According to Some)

Why Agile Methods Work (12Dec2012, Yaser Ghanam, www.infoq.com/articles/why-agile-methods-work):Focus on the Wildly Important. Short iterations can only deal with a very few features that the customer deems important -

or wildly important. Timeboxing these iterations forces the team to only choose a few goals that are achievable in a short time frame.

Act on the Lead Measures. What are these, those measures that control and predict better results (number of customers involved, etc?). What will be our “customer involvement” concept? Who and how many will play the role of the customer effectively with a real need? CAB members with serous needs for deployment of the information to solve a problem?

Keep a Compelling Scoreboard. What will be the progress scoreboard? The working team must design this.Create a Cadence of Accountability. “Having specific goals and clear lead measures defined, and having a compelling

scoreboard that engages everyone on the team, the team should regularly and frequently hold each other accountable for achieving the goals, improving the lead measures, and winning the game. The authors suggest a weekly meeting wherein everyone on the team should report briefly on whether they fulfilled their commitment to the team during the past week, how well they're contributing to the scoreboard, and what they want to commit to for the coming week. The authors recommend that every team member create their own commitment to have a sense of ownership. It is no longer about obeying your superiors but rather about keeping your promise to the team.

Bob Galen, 2012, Essential Patterns of Mature Agile Teams 1. Truly Emergent Architecture

2. Active Done-Ness 3. Truly Collaborative Work 4. Lean Work Queues 5. Aggressive Refactoring 6. Behaving Like a Team 7. Doing More than Thought Possible 8. Quality on ALL Fronts 9. Congruent Agile Measurement 10. Stopping the Line 11. Investing in Serious CI

12. Pervasive Product Owners 13. Righteous Retrospectives 14. The Power of Complete Transparency 15. Pursue Ruthless KISS 16. Testing is Everyone’s Job 17. The Nuance of a Healthy Backlog 18. Emphasize Strength-Based Teams 19. Performing Extraordinary Facilitation 20. Saying ‘NO’ as a Leader 21. Aligned Organizational Leadership

http://www.infoq.com/articles/why-agile-methods-work


On Being a Product OwnerView Bob Galen’s “The Essential Product Owner: Partnering with the Team” Webinar On-Demand, from AgileTrek, Toronto, November 12, 2012. View the recorded webinar on-demand now!The Product Owner (PO) role is arguably the most crucial role within agile teams. Unfortunately, we often hear horror stories about PO’s who are going it alone—who aren’t available to their teams, who change their minds incessantly on business priorities, and who ignore quality requirements and technical debt. Even the best PO’s struggle to meet the many demands of the business while still providing sufficient team guidance.Bob Galen shares real-world stories where he’s seen “effectively partnered” teams and Product Owners truly deliver balanced value for their business stakeholders. In this webinar he’ll show you how story mapping and release planning can truly set the stage for effective team workflow—establishing a “Big Picture” for everyone to shoot for. How establishing shared goals, both at the iteration and release levels, truly cements the partnership between team and Product Owner. And finally how setting a tempo of regular, focused backlog grooming sessions establishes a mechanism for the team and Product Owner to explore well-nuanced and high value backlogs.If you are a team or PO struggling to effectively deliver results, you’ll leave with ideas for establishing an ecosystem where the Product Owner and the team drive continuously improving performance.About the speakerBob Galen is an agile methodologist, practitioner, and coach who helps to guide companies and teams in their pragmatic adoption and organizational shift toward Scrum and other agile practices. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working in a wide variety of domains and regularly speaks at international conferences and professional groups. He is a Certified Scrum Master Practicing (CSP), Certified Scrum Product Owner (CSPO), and an active member of the Agile Alliance & Scrum Alliance. In 2009 he published the book Scrum Product Ownership – Balancing Value from the Inside Out.http://www.qaiagiletrek.org/2012/agiletrek-2012-webinar-series/the-essential-product-owner-webinar/

http://www.qaiagiletrek.org/2012/agiletrek-2012-webinar-series/the-essential-product-owner-webinar/

http://www.qaiagiletrek.org/2012/agiletrek-2012-webinar-series/the-essential-product-owner-webinar/


On Defining Tests for TDD

[Bob Galen, 2012, Essential Patterns of Mature Agile Teams]

Actively create Acceptance Tests on a Story or a Feature basis Customer heavily involved with definition Not functional tests Established a view to multiple levels of Done-Ness

Work – Done Story Acceptance Sprint Goals Release Criteria & Goals Think in terms of traditional Entry, Exit, and Release criteria


On Getting Started: Sprint Zerowww.infoq.com/news/2008/09/sprint_zero

Sprint Zero is a phrase that describe the planning which occurs prior to the first sprint.Make Sprint Zero as short as possible, e.g., one week. Here are three suggestions for getting started.

Take an initial sprint (called Sprint Zero, Iteration Zero, Inception Sprint, etc) that has the following goals:1. Get some quality items on the Product Backlog, 2. Provide a minimal environment that enables the writing of a quality deliverable, and 3. Write a piece of real deliverable material, no matter how small.

Use Iteration Zero as a spike – The planning team is responsible for producing 3 deliverables by the end of the planning iteration:4. A list of all prioritized features/stories with estimates5. A release plan that assigns each feature/story to an iteration/sprint6. A high-level application architecture, i.e. how the features will likely be implemented

Use a Zero Sprint to:7. estimate the most important features8. agree on a definition of done9. rebuild confidence with the customer

http://www.infoq.com/news/2008/09/sprint_zero


Sprint Zerohttp://scrummethodology.com/scrum-sprint-zero

So your organization has decided to implement Scrum, but you’re stuck, wondering what to do first. That’s understandable: For all of Scrum’s detailed processes, what’s the process for starting the process? Put another way, how does a team prepare for its first sprint? For many Scrum professionals, the answer is a sprint zero, a preliminary sprint exclusively dedicated to preparing for the first sprint. But which activities it includes, how long it lasts, and what it’s called are all debatable points.In my experience, this sprint is best spent focusing on the team’s physical environment. This might include setting up computers, creating a team room, optimizing work stations, etc. Others, however, conceive of sprint zero as a chance to prepare the team for its first sprint planning meeting. For those Scrum professionals, that means sprint zero involves adding a few substantial items to the backlog and writing a piece of functioning code — no matter how small. This argument does make sense: If the first sprint kicks off with the sprint planning meeting, a Product Owner will want to have some estimated items in the backlog.Since spending too much time on gathering requirements can lead to analysis paralysis, this sprint should be as short as possible — only as long as it takes to accomplish a few preparatory goals. Others, however, argue that sprint zero should be the same length as a regular sprint to help teams adjust to a regular work cadence. With that in mind, it’s not surprising that those who argue that sprint zero should be the same length as any other sprint also assert that it could just as easily be called sprint one. According to these Scrum professionals, the basic goals of sprint zero — design, infrastructure, process improvement, implementation, test, and validation — are the goals of every sprint.Sprint zero is contentious among Scrum practitioners. Though they might not all agree on its name or how long it should last, sprint zero preserves the principles and processes of the sprints to follow.

http://scrummethodology.com/scrum-sprint-zero

http://scrummethodology.com/the-scrum-team-role/

http://scrummethodology.com/scrum-sprint/

http://scrummethodology.com/the-scrum-team-role/

http://scrummethodology.com/scrum-meetings/

http://scrummethodology.com/the-scrum-backlog/


http://scrummethodology.com/scrum-product-owner/

http://scrummethodology.com/scrum-effort-estimation-and-story-points/



Jeff Patton. 2011. Using Design Thinking to Stop Building Worthless Software. InfoQ, www.infoq.com/presentations/Design-Thinking

http://www.infoq.com/presentations/Design-Thinking


Sprint Planning Meetinghttp://scrummethodology.com/scrum-meetings/

In Scrum, every iteration begins with the sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to four hours, this meeting is a conversation between the Product Owner and the team. It’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments. This is a good thing since the team may be aware of a legitimate impediment keeping the team from moving forward. When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. If a team uses manual agile, this might be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog. If a team uses an agile tooling solution, this might be represented in a number of ways. A tool my company uses, ScrumWorks® Pro, has a two-paned view of a project, in which the product backlog appears on the right and the sprint backlog on the left. Using an intuitive, drag-and-drop interface, the Product Owner can easily add stories to the sprint.At this point, the Product Owner is typically asked to leave while the team decomposes the sprint backlog items into tasks. While the Product Owner is asked to leave so that the team can candidly discuss the work, he or she is still expected to be “on call” to answer questions, clarify acceptance criteria, or renegotiate. This meeting, which was previously called the sprint definition meeting, is also time-boxed to four hours to limit all sprint planning activities to a single day’s time.Now that sprint goals are defined, the team is ready to get to work.Watch an example Sprint Planning Meeting.


http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm




http://scrummethodology.com/scrum-impediments/




http://agilemethodology.org/


http://www.danube.com/scrumworks/pro

http://www.danube.com/scrumworks/pro





http://scrummethodology.com/scrum-acceptance-criteria/

http://scrumtrainingseries.com/SprintPlanningMeeting/SprintPlanningMeeting.htm


Daily Standup, Sprint Review, and Retrospective Meetingshttp://scrummethodology.com/scrum-meetings/

The Daily Standup – The heart of the Scrum process is the daily standup meeting, also known as the daily Scrum. No other meeting captures Scrum’s emphasis on communication and transparency quite like the standup. This meeting helps ensure that the entire development team is always on the same page. Every day, the Scrum team gathers together, usually in a team room or private office—to report on the progress made since the last meeting, goals for the next one, and any impediments blocking their path. These reports are often phrased as responses to the following three questions:

• What have I done since the last Scrum meeting (yesterday)?• What will I do before the next Scrum meeting (tomorrow)?• What prevents me from performing my work as efficiently as possible?

This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, it is recommended they attend a “sidebar” meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.When the daily Scrum meeting is held is for the team and Product Owner to decide, but most Scrum literature encourages teams to hold the meeting as soon as all the team members arrive in the morning.Watch an example Daily Scrum Meeting.

Sprint Review and Retrospective Meetings – In Scrum, when the sprint ends, it’s time for the team to present its work to the Product Owner. This is known as the sprint review meeting. At this time, the Product Owner goes through the sprint backlog and asks the team to present its work. The Product Owner checks the work against the acceptance criteria to determine if the work is satisfactory or not. Even if only one percent of a story remains to be completed by a team, the Product Owner must reject the story as unfinished. Teams commonly discover that a story’s final touches often excise the most effort and time, so awarding partial credit for an incomplete story can contribute to a slanted velocity.After the sprint review meeting, the team and the ScrumMaster get together for the retrospective meeting. During this meeting, the team considers three things: what went well, what didn’t, and what improvements could be made in the next sprint. Since the Product Owner [in some cases] sits out this meeting, team members can speak frankly about the sprint’s successes and failures. It’s an especially important opportunity for the team to focus on its overall performance and identify strategies to improve its processes. Moreover, it allows the ScrumMaster to observe common impediments that impact the team and then work to resolve them.Watch an example Sprint Review Meeting and an example Sprint Retrospective Meeting.




http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htm





http://scrummethodology.com/scrum-acceptance-criteria/




http://scrumtrainingseries.com/SprintReviewMeeting/SprintReviewMeeting.htm

http://scrumtrainingseries.com/SprintRetrospectiveMeeting/SprintRetrospectiveMeeting.htm


Project Start Up Guidelines Version 130316

All projects should have a short documented “project description” that mark their transition from “start-up candidate” to “project in process”. These project descriptions should include certain minimal elements, and be one or two pages at most. Project descriptions should be periodically updated as the project activity reveals new understandings and useful clarifications. These will be the description of record, that at project completion, should represent the project accurately.

Project Description Guidance

Title – A unique and descriptive deliverable-product/resource title.

Project Leadership Traditional – one working group member as lead plus co-leads as appropriate (which may include non-INCOSE members) with core responsibility for project definition, team and technical management, and eventual completion quality and schedule.

or

Product Leadership Agile – (1) Designate (initial) Product Owner (PO), a single working group member (at any one time), responsible for the project description (with help as appropriate), responsible for representing the customer(s) to the project team, responsible for task and backlog prioritization, and responsible for completion quality. (2) Designate (initial) Scrum Master (SM), a single working group member responsible for team and technical project management to completion. PO and SM may be the same person, and may change throughout the project.

Customer(s) – The identity of the principle customer(s) – who will participate in establishing minimal but effective acceptance tests (our version of high level requirements), participate in periodic testing of incremental deliverables, and conduct V&V of the final results before the project is considered completed. Generally the customer(s) should include at least one seriously interested CAB member that will commit to involvement, though some projects may have the working group as the customer for projects that are necessary precursor foundations for subsequent CAB-customer projects.

Project Participants – a list of engaged and contributing project team members. Initially this list may simply be people who have declared interest in participation. In the end it should represent those who have contributed as part of the development team.

Deliverable Description – A brief (one paragraph or so) deliverable description/vision, that identifies the need and value of the INCOSE product/resource, and the nature of the deliverable.

Objectives/Goals – A succinct list of the objectives/goals of the project deliverable. These will be high level drivers for the final product V&V assessment.

Process – A succinct representation of the process that will be employed to accomplish project completion. Individual process activities should be listed with the need and intent for each, sufficient to inform project participants of the process


Project Leadership: Rick Dove as current Product Owner, Rick Dove as current Scrum Master.

Customer: Raytheon (initial test flight) and WG Membership.

Project Participants: Ron Lyells (Honeywell), Larri Rosser (Raytheon) et al. TBD.

Descriptive Statement:Collaborative knowledge development is a creative process that iteratively and incrementally discovers

high-value requirements and effective INCOSE-deliverable solutions. Distributed and volunteer collaborative work often has unpredictable and uncertain outcomes. This process recognizes that success occurs principally in a complicated and complex social environment, and must encourage passionate application of limited time, justifying an agile approach to collaborative knowledge development. This system’s purpose is to make the work environment and activities personally rewarding and effectively productive, by addressing the social issues of volunteered time, and ensuring that the results will be meaningful and useful. This INCOSE deliverable is an effective process that can be used and adapted for any WG collaborative development need.

Objectives/Goals:• Develop High Quality INCOSE Knowledge Products – with customer involvement in establishing and

conducting tests of effectiveness. MOE: Communicates actionable and meaningful knowledge verified by effective customer employment, with multiple customer potential.

• Rapid Convergence on Deliverable Product – with sort incremental iterations that converge on a final product. MOE: Final project deliverable on schedule (generally a few months).

• Effective distributed collaboration – with tools and teaming. MOE: Team participants opt in, find the collaboration process personally rewarding and productively effective, and would do it again under appropriate circumstances.

• Responsive to change – with recognition that work effort will discover beneficial changes to make in goals, tests, work-in-process, and the development process. MOE: Team participants contribute to discovery and alteration of original project goals and acceptance tests, change is embraced as valuable, change does not impact delivery date unacceptably, and change cost is felt to be negligible in total cost of producing a quality product.

Project Title: Agile Collaborative Development


Agile Collaborative DevelopmentKey Process-System Activities:

• Select/Describe Meaningful Projects. Need and intent: WG projects must fit the charter and produce results meaningful to INCOSE.

• Test-Driven Customer V&V. Need and intent: Rapid and verbal (not written) test feedback to the entire development team, to sustain development momentum and to allow Q&A for full understanding by all team members.

• Self-Motivated Participation. Need and intent: Project velocity and quality are accelerated when performed by empowered people with a personal interest in and/or need for the results.

• Manage with Disciplined Process. Need and intent: volunteer project participants may be remotely located and asynchronously active, and may enter and depart from projects-in-process activity. A clear and current operating procedure should be easily accessible to all at any time.

• Support with Collaboration Tools. Need and intent: Volunteers are committing their time for development, which should be supported with productivity tools that are easy to learn and access, and do not insert a personal expense barrier.

• Iterate Short Interim Deliverables. Need and intent: Incremental deliverables provide early feedback to developers and limit work-sprint to acceptable volunteer commitment.

• Pairing and Swarming. Need and intent: Pairing – reduce need for process training and documentation as one with experience informs the other; increase task quality with collaborative thinking. Swarming – maintain velocity by bringing many minds to bear immediately when a task-team gets stuck.

• Transparency of Decisions and Progress. Need and intent: Improve quality of decision making with early full team impact-feedback and concurrence; improve task velocity and quality with early identification of slippage, blockage, and cross-team dependency issues.

• Fluid PO/SM Roles. Need and intent: PO and SM personnel may have participation-time interrupted, and/or may find project-plan refactoring or specific iterations/tasks are better handled by others more knowledgeable.

• Refactor Tests, Task WIP, Process. Need and intent: Project progress reveals new understandings that should be refactored as changes to anything that can be improved.

• Recognize and Celebrate Progress. Need and intent: High team moral is known to improve project velocity and quality, so efforts should be made keep morale high.


Response Situation Analysis(Issues to Identify for ACD process)

Correction

Variation

Reconfigu-ration

Expansion(and

Contractionof Capacity)

Migration

Improvement

Modification(Add/Sub

Capability)

Creation(and

Elimination)

Pro

ac

tiv

eR

ea

cti

ve

Change Domain General Issues

What types of resource relationship configurations will need changed in the course of process operation?• ?• ?

What performance characteristics will the ACD process be expected to improve as it is used repeatedly?• ?• ?

What must an Agile Collaborative Development process be creating in the course of its operational activity?• ?• ?

What major event coming down the road will require a change in the initially adopted ACD infrastructure?• ?• ?

What modifications in resources-employed might need accommodation as the process is used?• ?• ?

What can go wrong that will need a highly responsive fix?• ?• ?

What process variables will range across what values and need accommodation?• ?• ?

What are “quantity-based” elastic-capacity needs on resources/output/activity/other?• ?• ?


Free Collaboration Toolshttp://www.google.com/+/learnmore/hangouts/ Free Live Meeting capabilityhttp://Scrumy.com for free project board – Scrumy Pro upgrade adds real-time

update, burndown, etc for $60/year (Dove has bought Scrumy Pro for WG test-flight project use)

http://doodle.com/ for polling (good for scheduling people meetings)http://www.freeconferencecall.com/Google Groups (Collaboration record with multiple task threads)Google Drive, Google Groups, SkyDrive, DropBoxSkype

Cloud storage is a security issue for some companies

http://www.google.com/+/learnmore/hangouts/

http://scrumy.com/

http://doodle.com/

http://www.freeconferencecall.com/


Test Flight ThoughtsOne project as test flight, with first (or more?) iterations done by IS13 for review there of process kinks and results quality.Maybe 1-2 week iterations multiples times over a 6 month or 12 month period?Iteration duration:• must allow for participant’s day job to be uninterrupted (and accommodate

unpredictable calls on time) and completion of the iteration. (1 week?)• must be short enough to keep the mind passionately engaged (1 week?)• must be short enough to allow an intense engagement that has a close end-of-

tunnel light, where life gets back to “normal” when done (1 week?) • (above are WG volunteer/productivity issues, below are system iteration issues)• must be short enough to permit inexpensive back tracking if wrong direction• there’s more…


Paul defers writing user

stories that describe

software features till the last

responsible moment.

Instead, he writes users

stories about the users and

what they need to

accomplish.

When working with Melanie

to estimate, he discusses all

the ways – sometimes as

many as 50 – that the user

can satisfy their goals.

Jeff Patton, Embrace Uncertainty. www.agileproductdesign.com/presentations/index.html

Project 4 and 5 did not do this. Project 6 did need (user accomplishment) and intent (paper feature) simultaneously rather than deferring intent – with the idea that intent could be changed.With out clear accessible user stories, projects 4 and 5 exhibited focus churn.


Pete & Roger’s Strategy: Build up feature quality iteration by iteration

This is Pete and

Roger

They have a problem. What they want may cost more than they can afford.

But, they know how to vary and build up quality to stay under budget, but maximize value.



enginetransmissionbrakessuspensionseatssteering wheelbeer cooler…

Hey – you need to

prioritize those!

He’s a real

doofus.

low cost moderate cost high cost

Pete & Roger prepare a

backlog for their bus

They know they need all the

features

But they know that all buses

don’t cost the same

Each essential feature varies

in quality affecting the final

cost



Pete and Roger have a handy heuristic for slicing up quality

Necessity: what minimal characteristics

are necessary for this feature?

Flexibility: what would make this feature

useful in more situations?

Safety: what would make this feature

safer for me to use?

Comfort, Luxury, and Performance: what

would make this feature more desirable to

use?



iterationsdesign &

development

1 2 3 4

feat

ure

s

release

Pete and Roger have learned the hard way that building each story to an ideal quality level is risky.

(Difficult to know how to finish a section until you can see how all the sections are developing)



1 2 3

Iterating affords building up quality over time

Pete and Roger leverage iteration



iterationsdesign &

development

1 2 3 4

use

r ta

sks

to

sup

po

rt

releaseD D D D D I IB- C C- D D D DA- B B- B B B B-A- A B A A- A- B-

Pete and Roger know that each bus feature can be split into user stories based on quality characteristics.

In early iterations Pete and Roger focus on necessity, then on flexibility and safety, then finish off with luxury

At each iteration they give their features a quality grade, then evaluate their bus report card.


[email protected], attributed copies permitted 1 generic agile collaborative development (acd)...

Documents