This document summarizes an agile workshop for managers and executive leadership at Cisco. The workshop covers several topics:
- Defining the role of an agile functional manager and transitioning existing managers to this role.
- Discussing whether the concept of "servant leadership" is too idealistic and assessing different leadership styles.
- Explaining the value of having a dedicated team room to facilitate transparency, collaboration and trust within agile teams.
The workshop provides guidance to leadership on adopting an inside-out approach to cultural change, emphasizing assessing organizational culture before implementing new processes or structures. Overall, the document outlines an agenda to help management explore how to effectively lead teams using agile and lean
Information Technology Project Management, Revised 7th edition test bank.docx
Agile lean workshop for managers & exec leadership
1. 1
Agile-Lean @ Cisco
Workshop for
Managers & Exec Leadership
Ravi Tadwalkar, Enterprise Agile Coach & Community Evangelist, Cisco Systems
April 2013, Attribution-NonCommercial-NoDerivs 3.0 Unported
Synopsis:
It has always been my pleasure to informally facilitate planning workshops for functional managers & exec leadership at and outside Cisco!
This workshop helps leadership in exploring how to be a good servant leader in a “control” culture that expects neck-down management style.
This Agile-Lean workshop for managers & exec leadership expands on what Pete Behrens refers to as "inside-out leadership agility”.
2. How does Cisco define
Agile Functional Manager?
Workshop “product tree” has roots based on agile/scrum values:
Focus, Commitment, Respect, Openness and…Courage
3. 3
Functional Manager
Usually DE & DT Managers fit in this role. Technical directors may also be good fit.
Core Responsibilities Additional Responsibilities Transition Stage
Retain people management
responsibilities
Creates an environment of
trust
Removes Impediments
Protects Teams From
Distractions
Recognizes and Rewards
agile behavior in teams and
individuals
Holds teams and individuals
accountable for their own
commitments
May also be SMEs,
Architects, Product Owners
- Have & set reasonable
expectations about transition,
i.e. team may stumble in initial
phase.
- Budget time, resources for
team needs e.g. Agile training,
infrastructure.
Agile Newbie
Required Training
for Scrum:
Scrum
Fundamentals for
Managers
- Introduce Slack to improve
effectiveness over efficiency
- May participate in or sponsor
Agile transition planning and
execution
Agile Practitioner
- Support innovation
- Fostering organizational
improvement
- Agile Portfolio Management
- Incorporate lean principles in
management
- Effective coaches of Agile &
lean principles
Agile Innovator
Become member
of Agile@Cisco
community
CAVEATS/ Don’ts:
For Functional Managers new to Agile, these
behaviors conflict with Agile Scrum;
• Decide what work needs to be done
• Assign the work to Team members
• Keep track of what everyone on the Team is doing
• Make sure the Team gets their work done
• Make commitments to management about how
much Team can do by a certain date
• Making commitments to management for the team
• Do weekly status update report for management
• Watch out for the drift back to old command-and-control
behaviors by manager assigning tasks to
team rather than team choosing it.
Note:
• Pete Deemer’s Manager 2.0: The Role of the
Manager in Scrum for more details
• Jurgen Appelo’s Management 3.0 workouts
4. Doesn’t “to lead is to serve”
sound too good to be true?
Workshop “product tree” has roots based on agile/scrum values:
Focus, Commitment, Respect, Openness and…Courage
5. 5
• Too good to be true: “To Lead is To Serve”?
• Leadership Assessment (Example)
• Summary based on assessment
• Peopleware Topics
Model of Team Room
Model of Daily Standup Meetings
Team Composition
Expectation Management: Status Updates, Predictability, Attitudes, Involvement & Quality
• What’s Culture?
• Why Inside-out Agility?
• Next Steps: GROW with InsideOut Coaching Training!
6. 6
• James Hunter’s Servant Leadership Implementation Process (source: jameshunter.com)
The process involves three steps that are implemented over a nine (9) month to one-year period and
includes:
• Foundation:
Setting the standard by training the team on the specifics of Servant Leadership and the required
leadership skills and behaviors.
• Feedback: Identifying the Gaps is accomplished utilizing a Leadership Skills Inventory (LSI) tool,
which is a 360° feedback tool clearly identifies the "gaps" between where the manager needs to be
as the leader versus their actual level of performance as the leader.
• Friction: Eliminating the Gaps & Measuring Results. Establishing specific and measurable goals
and measuring behavioral changes. A Continuous Improvement Panel (CIP) is created to provide
managers with support and provides the appropriate "friction" to ensure individual behavior change
until those changes become habit (second nature).
You can check out “The Servant Leadership Training Course” (audio MP3 CD set) on jameshunter.com
for servant leadership specific training on topics such as: Leadership Skills, Community/Team Building,
Active Listening, Assertiveness Training, Character Development, Constructive Discipline, Performance
Planning & Review.
7. 7
Popular example of leadership
assessment used by agile coaching
community:
Source:
James Hunter’s
“Servant Leadership Skills Inventory”
( aka LSI tool )
URL: http://www.jameshunter.com
8. 8
• Example summary of
leadership assessment
(source: jameshunter.com)
9. 9
• Typical functional management (power vs. authority) scenarios and possible workarounds for few of those.
This is based on conversations with several functional/non-functional managers.
• Almost everything in agile is centered on the team. Effective teams can overcome almost any obstacle. Pay
close attention to managing stakeholder expectations. Not establishing the correct expectations can create
genuine havoc in your project.
• You can get started with agile with or w/o tooling- leveraging on your visit to team room aka scrum room
and/or attending scrum team meetings.
• “Model” of Team room
Contact us (Agile-Lean@Cisco team) so we can coordinate with the Scrum Master to have access into the
“Kettle Drum” Scrum Room on a need-to-know basis. The only rule is not to interrupt the scrum team.
• “Model” of daily standup meetings
It is also possible to show-case a distributed scrum team to newbie teams/individuals. Newbie teams do
want to see a daily scrum meeting with scrum team in action. Team’s candid response has always been:
"We can certainly invite others to join to help them adopt more agile practices. (We have found it keeps us
honest to our agile practice too as we are less likely to slip into bad practices with others watching)"
10. 10
Team Composition
We suggest you look for these characteristics when forming an agile team:
• A team with every member willing to try agile
• A team that is curious and willing to adapt and learn
• A team willing to collaborate through constructive "storming" to have a better solution
• A team with diverse technical skills, willing to broaden skills by teaching and learning
• A team in which some members have domain expertise
• A team willing to foster strong communication skills
• A team with one or more agile champions
• A team with one or more experienced agile practitioners
• Co-located or distributed- the team should, at least, be willing to come together for coaching.
11. 11
• Expectation Management- Status Updates
• Productivity will go down at first and rise later. You should expect that it may take few iterations
for productivity to match pre-adoption levels. Pressure to speed up will force the team into
regressive behavior- such as wanting to go back to waterfall.
• Expectation Management- Predictability
• Good agile teams are known to be highly predictable, though during initial adoption the team’s
predictability will decline as the team learns about its capacity to produce. As a team matures in
its practices, a stable velocity will emerge leading to predictability.
12. 12
• Expectation Management- Attitudes
• There will be those that feel:
• Time is wasted in daily meetings
• Time is wasted testing even though we won’t deliver in this iteration
• Roles are not clear
• There is not enough project definition
• There is not enough documentation
• The team is not going fast enough
• …and so on.
13. 13
• Expectation Management- Involvement
• The role of every single person on the team will change.
• Project Managers will need to give up control. If they are scrum masters, they will have to be be servant leaders
• Product Owners will forgo detailed requirements documents
• Developers will need to develop incremental design and architecture skills
• UX - User experience will need to lead development by working iteratively and deliver artifacts that are less polished.
• QA engineers will start testing earlier to largely overlap code development
• The entire team takes ownership of requirements definition through testing.
• Expectation Management- Quality
• Product quality will stay the same or rise slightly in the first few iterations. The big gains in quality come later when the
team begins to adopt lean engineering practices like test first development, continuous integration and comprehensive
unit, functional and acceptance automation.
14. 14
• Check out this video
by Michael Sahota
• Example of cultural
assessment survey
(surveymonkey.com)
15. • Notice how Eric Ries’s “lean startup” method applies agile/lean for continuous innovation!
• 2 out of its 5 principles- “validated learning” & “build-measure-learn” require “inspect & adopt” & “reduce waste”
• However, large corporations use top-down approach toward agile adoption
• define process (formalize change) -> define structure (governance w/ silos) -> Culture (control)
• That’s why Pete Behrens’s “Inside-out agility” approach makes sense for “corp -> lean startup” morph!
• assess culture -> build org structure -> improve (process) with “inspect & adopt” & “reducing waste”.
Source: Pete Behrens’s slideshare: http://www.slideshare.net/petebehrens/leading-agility-insideout
16. 16
• Introduction
• The purpose of this training is to practice how to help manager improve his/her manager
effectiveness by asking to put all people managers through InsideOut Coaching training.
• InsideOut Coaching provides practical skills for all People Managers that are
immediately applicable to real-world situations. It's not just training and tools; it's a
paradigm shift with the power to create change. Managers learn to stop dictating
answers and help their team members find their own solutions – effectively unlocking the
spirit of innovation and creativity within each team member and enabling them to thrive.
• You can create a wiki page intended to provide a central repository of information about
InsideOut Coaching and a place where people managers can share their experiences,
their tips and tricks, and list events intended to continue the momentum around this
powerful coaching technique.
17. 17
• For a quick "hallway coaching" session, instead of using all the GROW questions, use
one question from each of the 4 sections, such as:
• 1. What do you want from this discussion? (s.m.a.r.t.)
2. Briefly, what's been happening?
3. If you were watching this conversation, what would you recommend?
4. What and when is the next step? (s.m.a.r.t.)
18. 18
D• escription Resource
Public InsideOut Web Site insideoutdev.com
InsideOut Coaching Web Site with licensed resources
such as videos and tools (requires password)
iocoachingcommunity.com
Tools (for printing) - GROW Pad, Coaching Strategy
and Feedback Form
Tools for printing
Tools (for editing) - GROW Pad, Coaching Strategy
and Feedback Form
Tools (for editing)
Alan Fine, creator of InsideOut Coaching, TED Talk Alan Fine TED Talk
Alan Fine's book "You Already Know How to Be Great:
A Simple Way to Remove Interference and Unlock
Your Greatest Potential"
You Already Know How to Be Great
Internal overview slide deck for sharing the basic ideas
of InsideOut Coaching with team members
InsideOut Coaching Debrief
19. Why do we need Team Room?
Workshop “product tree” has roots based on agile/scrum values:
Focus, Commitment, Respect, Openness and…Courage
21. 21
• Typical Myth- Functional Manager’s dilemma:
• "Team room does not work for us, since I cannot be sure a) whether people are really working, or b) people are doing
private work.”
• Scenario:
• This functional manager called for yet another all-hands. Team is fuming over too many and too long meetings.
• Symptoms:
• Micro-management; Lack of mutual trust; Not knowing team/project state causes anxiety
• Solution:
• Given that human brain mapping capability is spatial, persistent & tactile; a better materialization of this state is
helpful. Team room can be remedy for underlying trust factor. Team room enables transparent view of all agile
artifacts to all team members and stakeholders. Large companies create “model team-room“- not just a small “lean
startup” aspect anymore! Geo-distribution is possible with video conferencing, wikis for shared editing
• Team room is also a multi-purpose room where gamestorming supplements brainstorming; besides teams
highlighting their impediments / blockers / obstacles. Visit team-room page for demos & examples of how distributed
teams collaborate with product managers/owners, leads & scrum masters.
22. 22
• What’s typical engineering dilemma?
• Managers (Functional & PMO) chase engineers on talks all the time
• What’s the pitfall?
• Productivity & quality at stake, resulting in rework
• What’s the rescue situation?
• Managers should let go (control): enable self-organizing teams by creating team rooms
• How to avoid the pitfall
• Enable team to have generalists so as to self-assign work with no pressure from “seagulls”. Let’s talk about “How?”
• Team formation guidance:
• Promote team room based collaboration, create culture of co-location
• Form teams around portfolio/product level feature teams instead of component teams
• Managers should train/mentor/coach team members so that they become generalists
• Empower teams to become self-organizing “nirvana” state- by giving them your office for teamwork!
• Engineers should collaborate in those “transient” team rooms for daily standups in front of task boards
• Scrum Masters & POs should collaborate for obstacle removal in front of obstacle boards
23. What “fruits” (or questions)
do you want to add?
Workshop “product tree” has roots based on agile/scrum values:
Focus, Commitment, Respect, Openness and…Courage
24. 24
• How to empower feature teams to make decisions without continuous oversight by us?
• How to create feature teams without enough PdM, Architect & UE lead in xyz location?
• Team is not documenting their software when “swarming” during iterative development, beyond
generating API docs. We expect SFS instead, and sometime end up thinking “the agile manifesto
about ‘working software over documentation’ is wrong”.
• How do we share engineers across programs to stay within budget?
• How do we prioritize new features vs. retiring “technical debt”(recapitalization of core functionality
to modernize it)?
• In exec leadership workshop, one senior exec states the importance of stage-gates during
iterative development, but there are very few in the audience that can smell scrum-but here. What
would you do to get the crowd on track otherwise? You are up against crowd wisdom now.
• How would you convince BU execs that their first agile experience will be not so pleasant? How
will you mentor senior execs who tell you they will not (want to) fail at any cost?
Notas del editor
Agile-Lean workshop for managers & exec leadership by Ravi Tadwalkar is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Based on Pete Behrens’s work at http://www.slideshare.net/petebehrens/leading-agility-insideout
Based on Alan Fine, creator of InsideOut Coaching, source: insideoutdev.com
Based on Alan Fine, creator of InsideOut Coaching, source: insideoutdev.com
Based on Jurgen Appelo’s “management 3.0” related work, such as: http://www.slideshare.net/jurgenappelo/checklist-for-the-agile-manager
Agile/Lean fundamentals
"self-paced training" section
Agile Manifesto
What is Agile & Why Agile
What is Lean & Why Lean
Agile Lean at Cisco Program- "What We Do" deck
Focus on "starter kit" documentation e.g. "Agile Roles & Responsibilities"- both deck & doc
Servant leadership examples & assessment tools
sample audio/video/quotes
from Lyssa Adkins, mainly from coachingagileteams.com
from James Hunter, mainly from jameshunter.com
Peopleware Topics
Typical functional management (power vs. authority) scenarios at Cisco and possible workarounds for some of those. This is based on conversations with several functional/non-functional managers.
Servant leadership related content, with concrete exercises (this is a soft skill that is extremely hard to coach, teach or mentor)
LSI (Leadership Skills Inventory) based assessment handout/exercise/vovici
Promote team room based collaboration, create culture of co-location
Schneider's culture model (Michael Sahota video)
cultural assessment handout/exercise/vovici
Team formation guidance
team-room wiki page
High level Cisco examples of how engineering management can collaborate with product management on defining product vision, roadmap, release planning & backlog grooming from Agile Product Management page
jabber video demo of CBABU team-room
Process training
The motivation to move to agile
sharing road show material with managers for exec buy-in (CBABU pioneer award entry deck as handout)
Pete Behren's "inside-out agility" presentation
Scrum/Kanban difference
Guidance for management on when to choose what- agile/scrum and lean/kanban.
When neither agile nor lean makes sense and perhaps waterfall/RUP is better choice
e.g. release planning may not be feasible for pure R&D initatives like CSDN project or really complex BI projects like GMI project where Ken Collier's "agile analytics" approach may be more practical.
I can imagine firmware development project teams e.g. CENBU. These projects cannot avoid what they do currently, hoping to optimize on flow at best, using lean principles (and not kanban process as such).
I think taking stance on one standardized process can prove to be disastrous for enterprise level agile adoption.
Challenges of Agile Transition
Agile transition model like SAFe or Flow-Pull-Innovate looks great in books & experience reports, but will that work for you? It feels like watching those commercial ads when you read stuff. Get advice from internal coaches' network.
Common pain points and scenarios listed during internal coaches' meetings
Creating Backlog during Release Planning
Creating tasks during Sprint Planning
Are you kidding- Working Software Over Documentation?
http://iwe.cisco.com/web/standard-agile/cpdm-standard-agile-training
Jeff Marr's slides from "before & after" deck, e.g. sample release timelines, AC goals, Sprint 0 goals
Examples of Agile Commit templates at various "scales" of program- small, medium & large
Examples of Architectural design documentation
James Whittaker's "10-minute test plan" handout- may not work for really large programs with external vendors
Overview of Agile metrics
BSC metrics (in beta as of April 2013)
References:
CPDM Standard Agile “Starter Kit”; URL: http://wwwin.cisco.com/tech/EngCoE/agile/starter-kit.shtml (Read Roles ‘n Responsibilities EDCS-1139525)
* Check Cisco Agile Playbook definition of Engineering Manager for CBABU’s additions to Cisco CPDM Standard Agile source mentioned above:
http://devplaybook.cisco.com:8080/download/attachments/2228378/Agile%20Role%20-%20Engineering%20Manager.pptx?version=2&modificationDate=1399336813000&api=v2
Agile/Lean fundamentals
"self-paced training" section
Agile Manifesto
What is Agile & Why Agile
What is Lean & Why Lean
Agile Lean at Cisco Program- "What We Do" deck
Focus on "starter kit" documentation e.g. "Agile Roles & Responsibilities"- both deck & doc
Servant leadership examples & assessment tools
sample audio/video/quotes
from Lyssa Adkins, mainly from coachingagileteams.com
from James Hunter, mainly from jameshunter.com
Peopleware Topics
Typical functional management (power vs. authority) scenarios at Cisco and possible workarounds for some of those. This is based on conversations with several functional/non-functional managers.
Servant leadership related content, with concrete exercises (this is a soft skill that is extremely hard to coach, teach or mentor)
LSI (Leadership Skills Inventory) based assessment handout/exercise/vovici
Promote team room based collaboration, create culture of co-location
Schneider's culture model (Michael Sahota video)
cultural assessment handout/exercise/vovici
Team formation guidance
team-room wiki page
High level Cisco examples of how engineering management can collaborate with product management on defining product vision, roadmap, release planning & backlog grooming from Agile Product Management page
jabber video demo of CBABU team-room
Process training
The motivation to move to agile
sharing road show material with managers for exec buy-in (CBABU pioneer award entry deck as handout)
Pete Behren's "inside-out agility" presentation
Scrum/Kanban difference
Guidance for management on when to choose what- agile/scrum and lean/kanban.
When neither agile nor lean makes sense and perhaps waterfall/RUP is better choice
e.g. release planning may not be feasible for pure R&D initatives like CSDN project or really complex BI projects like GMI project where Ken Collier's "agile analytics" approach may be more practical.
I can imagine firmware development project teams e.g. CENBU. These projects cannot avoid what they do currently, hoping to optimize on flow at best, using lean principles (and not kanban process as such).
I think taking stance on one standardized process can prove to be disastrous for enterprise level agile adoption.
Challenges of Agile Transition
Agile transition model like SAFe or Flow-Pull-Innovate looks great in books & experience reports, but will that work for you? It feels like watching those commercial ads when you read stuff. Get advice from internal coaches' network.
Common pain points and scenarios listed during internal coaches' meetings
Creating Backlog during Release Planning
Creating tasks during Sprint Planning
Are you kidding- Working Software Over Documentation?
http://iwe.cisco.com/web/standard-agile/cpdm-standard-agile-training
Jeff Marr's slides from "before & after" deck, e.g. sample release timelines, AC goals, Sprint 0 goals
Examples of Agile Commit templates at various "scales" of program- small, medium & large
Examples of Architectural design documentation
James Whittaker's "10-minute test plan" handout- may not work for really large programs with external vendors
Overview of Agile metrics
BSC metrics (in beta as of April 2013)
Hint: play audio clip from James Hunter’s audio set here and show the pictures
Hint: play audio clip from James Hunter’s audio set here, and show the pictures of example “radar chart” assessments
Hint: play audio clip here and show the pictures
Want to see how Agile / Scrum works at Cisco?
You can get started with agile with or w/o tooling- leveraging on your visit to CBABU team room aka scrum room and/or attending CSTG IPS-SDT scrum team meetings. Almost everything in agile is centered on the team. Effective teams can overcome almost any obstacle. Pay close attention to managing stakeholder expectations. Not establishing the correct expectations can create genuine havoc in your project. We have some suggestions for you.
CBABU team room aka "scrum room"
CBABU teams have been a leader in Agile practices within CCG (VTG) and is willing to share practices across Cisco to support agile adoption effort.
Contact us (Agile Lean at Cisco team) so we can coordinate with the Scrum Master to have access into the “Kettle Drum” Scrum Room on a need-to-know basis.
The only rule is not to interrupt the scrum team.
CSTG IPS-SDTscrum team meetings
It is also possible to show-case IPS-SDT team to newbie teams/individuals, as part of their agile adoption process. Newbie teams do want to see a daily scrum meeting with scrum team in action.
We (Agile@Cisco team) will coordinate with IPS-SDT team each time we get such a request. Their candid response has always been: "We can certainly invite others to join to help them adopt more agile practices. (We have found it keeps us honest to our agile practice too as we are less likely to slip into bad practices with others watching)"
Team Composition
We suggest you look for these characteristics when forming an agile team:
A team with every member willing to try agile
A team that is curious and willing to adapt and learn
A team willing to collaborate through constructive "storming" to have a better solution
A team with diverse technical skills, willing to broaden skills by teaching and learning
A team in which some members have domain expertise
A team willing to foster strong communication skills
A team with one or more agile champions
A team with one or more experienced agile practitioners
Co-located or distributed- the team should, at least, be willing to come together for coaching.
Expectation Management
Progress
Productivity will go down at first and rise later. You should expect that it may take few iterations for productivity to match pre-adoption levels. Pressure to speed up will force the team into regressive behavior- such as wanting to go back to waterfall.
Predictability
Good agile teams are known to be highly predictable, though during initial adoption the team’s predictability will decline as the team learns about its capacity to produce. As a team matures in its practices, a stable velocity will emerge leading to predictability.
Attitudes
There will be those that feel:
Time is wasted in daily meetings
Time is wasted testing even though we won’t deliver in this iteration
Roles are not clear
There is not enough project definition
There is not enough documentation
The team is not going fast enough
…and so on.
Involvement
The role of every single person on the team will change.
Project Managers will need to give up control
Product Owners will forgo detailed requirements documents
Developers will need to develop incremental design and architecture skills
UX - User experience will need to lead development by working iteratively and deliver artifacts that are less polished.
QA engineers will start testing earlier to largely overlap code development
Scrum masters will be servant leaders
The entire team takes ownership of requirements definition through testing.
Quality
Product quality will stay the same or rise slightly in the first few iterations. The big gains in quality come later when the team begins to adopt lean engineering practices like test first development, continuous integration and comprehensive unit, functional and acceptance automation.
Want to see how Agile / Scrum works at Cisco?
You can get started with agile with or w/o tooling- leveraging on your visit to CBABU team room aka scrum room and/or attending CSTG IPS-SDT scrum team meetings. Almost everything in agile is centered on the team. Effective teams can overcome almost any obstacle. Pay close attention to managing stakeholder expectations. Not establishing the correct expectations can create genuine havoc in your project. We have some suggestions for you.
CBABU team room aka "scrum room"
CBABU teams have been a leader in Agile practices within CCG (VTG) and is willing to share practices across Cisco to support agile adoption effort.
Contact us (Agile Lean at Cisco team) so we can coordinate with the Scrum Master to have access into the “Kettle Drum” Scrum Room on a need-to-know basis.
The only rule is not to interrupt the scrum team.
CSTG IPS-SDTscrum team meetings
It is also possible to show-case IPS-SDT team to newbie teams/individuals, as part of their agile adoption process. Newbie teams do want to see a daily scrum meeting with scrum team in action.
We (Agile@Cisco team) will coordinate with IPS-SDT team each time we get such a request. Their candid response has always been: "We can certainly invite others to join to help them adopt more agile practices. (We have found it keeps us honest to our agile practice too as we are less likely to slip into bad practices with others watching)"
Team Composition
We suggest you look for these characteristics when forming an agile team:
A team with every member willing to try agile
A team that is curious and willing to adapt and learn
A team willing to collaborate through constructive "storming" to have a better solution
A team with diverse technical skills, willing to broaden skills by teaching and learning
A team in which some members have domain expertise
A team willing to foster strong communication skills
A team with one or more agile champions
A team with one or more experienced agile practitioners
Co-located or distributed- the team should, at least, be willing to come together for coaching.
Expectation Management
Progress
Productivity will go down at first and rise later. You should expect that it may take few iterations for productivity to match pre-adoption levels. Pressure to speed up will force the team into regressive behavior- such as wanting to go back to waterfall.
Predictability
Good agile teams are known to be highly predictable, though during initial adoption the team’s predictability will decline as the team learns about its capacity to produce. As a team matures in its practices, a stable velocity will emerge leading to predictability.
Attitudes
There will be those that feel:
Time is wasted in daily meetings
Time is wasted testing even though we won’t deliver in this iteration
Roles are not clear
There is not enough project definition
There is not enough documentation
The team is not going fast enough
…and so on.
Involvement
The role of every single person on the team will change.
Project Managers will need to give up control
Product Owners will forgo detailed requirements documents
Developers will need to develop incremental design and architecture skills
UX - User experience will need to lead development by working iteratively and deliver artifacts that are less polished.
QA engineers will start testing earlier to largely overlap code development
Scrum masters will be servant leaders
The entire team takes ownership of requirements definition through testing.
Quality
Product quality will stay the same or rise slightly in the first few iterations. The big gains in quality come later when the team begins to adopt lean engineering practices like test first development, continuous integration and comprehensive unit, functional and acceptance automation.
Want to see how Agile / Scrum works at Cisco?
You can get started with agile with or w/o tooling- leveraging on your visit to CBABU team room aka scrum room and/or attending CSTG IPS-SDT scrum team meetings. Almost everything in agile is centered on the team. Effective teams can overcome almost any obstacle. Pay close attention to managing stakeholder expectations. Not establishing the correct expectations can create genuine havoc in your project. We have some suggestions for you.
CBABU team room aka "scrum room"
CBABU teams have been a leader in Agile practices within CCG (VTG) and is willing to share practices across Cisco to support agile adoption effort.
Contact us (Agile Lean at Cisco team) so we can coordinate with the Scrum Master to have access into the “Kettle Drum” Scrum Room on a need-to-know basis.
The only rule is not to interrupt the scrum team.
CSTG IPS-SDTscrum team meetings
It is also possible to show-case IPS-SDT team to newbie teams/individuals, as part of their agile adoption process. Newbie teams do want to see a daily scrum meeting with scrum team in action.
We (Agile@Cisco team) will coordinate with IPS-SDT team each time we get such a request. Their candid response has always been: "We can certainly invite others to join to help them adopt more agile practices. (We have found it keeps us honest to our agile practice too as we are less likely to slip into bad practices with others watching)"
Team Composition
We suggest you look for these characteristics when forming an agile team:
A team with every member willing to try agile
A team that is curious and willing to adapt and learn
A team willing to collaborate through constructive "storming" to have a better solution
A team with diverse technical skills, willing to broaden skills by teaching and learning
A team in which some members have domain expertise
A team willing to foster strong communication skills
A team with one or more agile champions
A team with one or more experienced agile practitioners
Co-located or distributed- the team should, at least, be willing to come together for coaching.
Expectation Management
Progress
Productivity will go down at first and rise later. You should expect that it may take few iterations for productivity to match pre-adoption levels. Pressure to speed up will force the team into regressive behavior- such as wanting to go back to waterfall.
Predictability
Good agile teams are known to be highly predictable, though during initial adoption the team’s predictability will decline as the team learns about its capacity to produce. As a team matures in its practices, a stable velocity will emerge leading to predictability.
Attitudes
There will be those that feel:
Time is wasted in daily meetings
Time is wasted testing even though we won’t deliver in this iteration
Roles are not clear
There is not enough project definition
There is not enough documentation
The team is not going fast enough
…and so on.
Involvement
The role of every single person on the team will change.
Project Managers will need to give up control
Product Owners will forgo detailed requirements documents
Developers will need to develop incremental design and architecture skills
UX - User experience will need to lead development by working iteratively and deliver artifacts that are less polished.
QA engineers will start testing earlier to largely overlap code development
Scrum masters will be servant leaders
The entire team takes ownership of requirements definition through testing.
Quality
Product quality will stay the same or rise slightly in the first few iterations. The big gains in quality come later when the team begins to adopt lean engineering practices like test first development, continuous integration and comprehensive unit, functional and acceptance automation.
Want to see how Agile / Scrum works at Cisco?
You can get started with agile with or w/o tooling- leveraging on your visit to CBABU team room aka scrum room and/or attending CSTG IPS-SDT scrum team meetings. Almost everything in agile is centered on the team. Effective teams can overcome almost any obstacle. Pay close attention to managing stakeholder expectations. Not establishing the correct expectations can create genuine havoc in your project. We have some suggestions for you.
CBABU team room aka "scrum room"
CBABU teams have been a leader in Agile practices within CCG (VTG) and is willing to share practices across Cisco to support agile adoption effort.
Contact us (Agile Lean at Cisco team) so we can coordinate with the Scrum Master to have access into the “Kettle Drum” Scrum Room on a need-to-know basis.
The only rule is not to interrupt the scrum team.
CSTG IPS-SDTscrum team meetings
It is also possible to show-case IPS-SDT team to newbie teams/individuals, as part of their agile adoption process. Newbie teams do want to see a daily scrum meeting with scrum team in action.
We (Agile@Cisco team) will coordinate with IPS-SDT team each time we get such a request. Their candid response has always been: "We can certainly invite others to join to help them adopt more agile practices. (We have found it keeps us honest to our agile practice too as we are less likely to slip into bad practices with others watching)"
Team Composition
We suggest you look for these characteristics when forming an agile team:
A team with every member willing to try agile
A team that is curious and willing to adapt and learn
A team willing to collaborate through constructive "storming" to have a better solution
A team with diverse technical skills, willing to broaden skills by teaching and learning
A team in which some members have domain expertise
A team willing to foster strong communication skills
A team with one or more agile champions
A team with one or more experienced agile practitioners
Co-located or distributed- the team should, at least, be willing to come together for coaching.
Expectation Management
Progress
Productivity will go down at first and rise later. You should expect that it may take few iterations for productivity to match pre-adoption levels. Pressure to speed up will force the team into regressive behavior- such as wanting to go back to waterfall.
Predictability
Good agile teams are known to be highly predictable, though during initial adoption the team’s predictability will decline as the team learns about its capacity to produce. As a team matures in its practices, a stable velocity will emerge leading to predictability.
Attitudes
There will be those that feel:
Time is wasted in daily meetings
Time is wasted testing even though we won’t deliver in this iteration
Roles are not clear
There is not enough project definition
There is not enough documentation
The team is not going fast enough
…and so on.
Involvement
The role of every single person on the team will change.
Project Managers will need to give up control
Product Owners will forgo detailed requirements documents
Developers will need to develop incremental design and architecture skills
UX - User experience will need to lead development by working iteratively and deliver artifacts that are less polished.
QA engineers will start testing earlier to largely overlap code development
Scrum masters will be servant leaders
The entire team takes ownership of requirements definition through testing.
Quality
Product quality will stay the same or rise slightly in the first few iterations. The big gains in quality come later when the team begins to adopt lean engineering practices like test first development, continuous integration and comprehensive unit, functional and acceptance automation.
Want to see how Agile / Scrum works at Cisco?
You can get started with agile with or w/o tooling- leveraging on your visit to CBABU team room aka scrum room and/or attending CSTG IPS-SDT scrum team meetings. Almost everything in agile is centered on the team. Effective teams can overcome almost any obstacle. Pay close attention to managing stakeholder expectations. Not establishing the correct expectations can create genuine havoc in your project. We have some suggestions for you.
CBABU team room aka "scrum room"
CBABU teams have been a leader in Agile practices within CCG (VTG) and is willing to share practices across Cisco to support agile adoption effort.
Contact us (Agile Lean at Cisco team) so we can coordinate with the Scrum Master to have access into the “Kettle Drum” Scrum Room on a need-to-know basis.
The only rule is not to interrupt the scrum team.
CSTG IPS-SDTscrum team meetings
It is also possible to show-case IPS-SDT team to newbie teams/individuals, as part of their agile adoption process. Newbie teams do want to see a daily scrum meeting with scrum team in action.
We (Agile@Cisco team) will coordinate with IPS-SDT team each time we get such a request. Their candid response has always been: "We can certainly invite others to join to help them adopt more agile practices. (We have found it keeps us honest to our agile practice too as we are less likely to slip into bad practices with others watching)"
Team Composition
We suggest you look for these characteristics when forming an agile team:
A team with every member willing to try agile
A team that is curious and willing to adapt and learn
A team willing to collaborate through constructive "storming" to have a better solution
A team with diverse technical skills, willing to broaden skills by teaching and learning
A team in which some members have domain expertise
A team willing to foster strong communication skills
A team with one or more agile champions
A team with one or more experienced agile practitioners
Co-located or distributed- the team should, at least, be willing to come together for coaching.
Expectation Management
Progress
Productivity will go down at first and rise later. You should expect that it may take few iterations for productivity to match pre-adoption levels. Pressure to speed up will force the team into regressive behavior- such as wanting to go back to waterfall.
Predictability
Good agile teams are known to be highly predictable, though during initial adoption the team’s predictability will decline as the team learns about its capacity to produce. As a team matures in its practices, a stable velocity will emerge leading to predictability.
Attitudes
There will be those that feel:
Time is wasted in daily meetings
Time is wasted testing even though we won’t deliver in this iteration
Roles are not clear
There is not enough project definition
There is not enough documentation
The team is not going fast enough
…and so on.
Involvement
The role of every single person on the team will change.
Project Managers will need to give up control
Product Owners will forgo detailed requirements documents
Developers will need to develop incremental design and architecture skills
UX - User experience will need to lead development by working iteratively and deliver artifacts that are less polished.
QA engineers will start testing earlier to largely overlap code development
Scrum masters will be servant leaders
The entire team takes ownership of requirements definition through testing.
Quality
Product quality will stay the same or rise slightly in the first few iterations. The big gains in quality come later when the team begins to adopt lean engineering practices like test first development, continuous integration and comprehensive unit, functional and acceptance automation.
Agile/Lean fundamentals
"self-paced training" section
Agile Manifesto
What is Agile & Why Agile
What is Lean & Why Lean
Agile Lean at Cisco Program- "What We Do" deck
Focus on "starter kit" documentation e.g. "Agile Roles & Responsibilities"- both deck & doc
Servant leadership examples & assessment tools
sample audio/video/quotes
from Lyssa Adkins, mainly from coachingagileteams.com
from James Hunter, mainly from jameshunter.com
Peopleware Topics
Typical functional management (power vs. authority) scenarios at Cisco and possible workarounds for some of those. This is based on conversations with several functional/non-functional managers.
Servant leadership related content, with concrete exercises (this is a soft skill that is extremely hard to coach, teach or mentor)
LSI (Leadership Skills Inventory) based assessment handout/exercise/vovici
Promote team room based collaboration, create culture of co-location
Schneider's culture model (Michael Sahota video)
cultural assessment handout/exercise/vovici
Team formation guidance
team-room wiki page
High level Cisco examples of how engineering management can collaborate with product management on defining product vision, roadmap, release planning & backlog grooming from Agile Product Management page
jabber video demo of CBABU team-room
Process training
The motivation to move to agile
sharing road show material with managers for exec buy-in (CBABU pioneer award entry deck as handout)
Pete Behren's "inside-out agility" presentation
Scrum/Kanban difference
Guidance for management on when to choose what- agile/scrum and lean/kanban.
When neither agile nor lean makes sense and perhaps waterfall/RUP is better choice
e.g. release planning may not be feasible for pure R&D initatives like CSDN project or really complex BI projects like GMI project where Ken Collier's "agile analytics" approach may be more practical.
I can imagine firmware development project teams e.g. CENBU. These projects cannot avoid what they do currently, hoping to optimize on flow at best, using lean principles (and not kanban process as such).
I think taking stance on one standardized process can prove to be disastrous for enterprise level agile adoption.
Challenges of Agile Transition
Agile transition model like SAFe or Flow-Pull-Innovate looks great in books & experience reports, but will that work for you? It feels like watching those commercial ads when you read stuff. Get advice from internal coaches' network.
Common pain points and scenarios listed during internal coaches' meetings
Creating Backlog during Release Planning
Creating tasks during Sprint Planning
Are you kidding- Working Software Over Documentation?
http://iwe.cisco.com/web/standard-agile/cpdm-standard-agile-training
Jeff Marr's slides from "before & after" deck, e.g. sample release timelines, AC goals, Sprint 0 goals
Examples of Agile Commit templates at various "scales" of program- small, medium & large
Examples of Architectural design documentation
James Whittaker's "10-minute test plan" handout- may not work for really large programs with external vendors
Overview of Agile metrics
BSC metrics (in beta as of April 2013)
Agile/Lean fundamentals
"self-paced training" section
Agile Manifesto
What is Agile & Why Agile
What is Lean & Why Lean
Agile Lean at Cisco Program- "What We Do" deck
Focus on "starter kit" documentation e.g. "Agile Roles & Responsibilities"- both deck & doc
Servant leadership examples & assessment tools
sample audio/video/quotes
from Lyssa Adkins, mainly from coachingagileteams.com
from James Hunter, mainly from jameshunter.com
Peopleware Topics
Typical functional management (power vs. authority) scenarios at Cisco and possible workarounds for some of those. This is based on conversations with several functional/non-functional managers.
Servant leadership related content, with concrete exercises (this is a soft skill that is extremely hard to coach, teach or mentor)
LSI (Leadership Skills Inventory) based assessment handout/exercise/vovici
Promote team room based collaboration, create culture of co-location
Schneider's culture model (Michael Sahota video)
cultural assessment handout/exercise/vovici
Team formation guidance
team-room wiki page
High level Cisco examples of how engineering management can collaborate with product management on defining product vision, roadmap, release planning & backlog grooming from Agile Product Management page
jabber video demo of CBABU team-room
Process training
The motivation to move to agile
sharing road show material with managers for exec buy-in (CBABU pioneer award entry deck as handout)
Pete Behren's "inside-out agility" presentation
Scrum/Kanban difference
Guidance for management on when to choose what- agile/scrum and lean/kanban.
When neither agile nor lean makes sense and perhaps waterfall/RUP is better choice
e.g. release planning may not be feasible for pure R&D initatives like CSDN project or really complex BI projects like GMI project where Ken Collier's "agile analytics" approach may be more practical.
I can imagine firmware development project teams e.g. CENBU. These projects cannot avoid what they do currently, hoping to optimize on flow at best, using lean principles (and not kanban process as such).
I think taking stance on one standardized process can prove to be disastrous for enterprise level agile adoption.
Challenges of Agile Transition
Agile transition model like SAFe or Flow-Pull-Innovate looks great in books & experience reports, but will that work for you? It feels like watching those commercial ads when you read stuff. Get advice from internal coaches' network.
Common pain points and scenarios listed during internal coaches' meetings
Creating Backlog during Release Planning
Creating tasks during Sprint Planning
Are you kidding- Working Software Over Documentation?
http://iwe.cisco.com/web/standard-agile/cpdm-standard-agile-training
Jeff Marr's slides from "before & after" deck, e.g. sample release timelines, AC goals, Sprint 0 goals
Examples of Agile Commit templates at various "scales" of program- small, medium & large
Examples of Architectural design documentation
James Whittaker's "10-minute test plan" handout- may not work for really large programs with external vendors
Overview of Agile metrics
BSC metrics (in beta as of April 2013)
Agile/Lean fundamentals
"self-paced training" section
Agile Manifesto
What is Agile & Why Agile
What is Lean & Why Lean
Agile Lean at Cisco Program- "What We Do" deck
Focus on "starter kit" documentation e.g. "Agile Roles & Responsibilities"- both deck & doc
Servant leadership examples & assessment tools
sample audio/video/quotes
from Lyssa Adkins, mainly from coachingagileteams.com
from James Hunter, mainly from jameshunter.com
Peopleware Topics
Typical functional management (power vs. authority) scenarios at Cisco and possible workarounds for some of those. This is based on conversations with several functional/non-functional managers.
Servant leadership related content, with concrete exercises (this is a soft skill that is extremely hard to coach, teach or mentor)
LSI (Leadership Skills Inventory) based assessment handout/exercise/vovici
Promote team room based collaboration, create culture of co-location
Schneider's culture model (Michael Sahota video)
cultural assessment handout/exercise/vovici
Team formation guidance
team-room wiki page
High level Cisco examples of how engineering management can collaborate with product management on defining product vision, roadmap, release planning & backlog grooming from Agile Product Management page
jabber video demo of CBABU team-room
Process training
The motivation to move to agile
sharing road show material with managers for exec buy-in (CBABU pioneer award entry deck as handout)
Pete Behren's "inside-out agility" presentation
Scrum/Kanban difference
Guidance for management on when to choose what- agile/scrum and lean/kanban.
When neither agile nor lean makes sense and perhaps waterfall/RUP is better choice
e.g. release planning may not be feasible for pure R&D initatives like CSDN project or really complex BI projects like GMI project where Ken Collier's "agile analytics" approach may be more practical.
I can imagine firmware development project teams e.g. CENBU. These projects cannot avoid what they do currently, hoping to optimize on flow at best, using lean principles (and not kanban process as such).
I think taking stance on one standardized process can prove to be disastrous for enterprise level agile adoption.
Challenges of Agile Transition
Agile transition model like SAFe or Flow-Pull-Innovate looks great in books & experience reports, but will that work for you? It feels like watching those commercial ads when you read stuff. Get advice from internal coaches' network.
Common pain points and scenarios listed during internal coaches' meetings
Creating Backlog during Release Planning
Creating tasks during Sprint Planning
Are you kidding- Working Software Over Documentation?
http://iwe.cisco.com/web/standard-agile/cpdm-standard-agile-training
Jeff Marr's slides from "before & after" deck, e.g. sample release timelines, AC goals, Sprint 0 goals
Examples of Agile Commit templates at various "scales" of program- small, medium & large
Examples of Architectural design documentation
James Whittaker's "10-minute test plan" handout- may not work for really large programs with external vendors
Overview of Agile metrics
BSC metrics (in beta as of April 2013)