Here are my rough notes from the May 2005 Scrum Gathering in Boston. Regrettably I was not in the room for most of Mike Cohn’s presentation on User Stories… but his book (User Stories Applied : For Agile Software Development) is excellent 🙂

The notes in this entry include predictions from Ken Schwaber, a presentation from Bob Schatz formerly of Primavera on their enterprise-wide implementation of Scrum, a panel discussion with Tim Bacon, Jeff McKenna, and Diana Larsen, moderated by Esther Derby. In the afternoon we heard from Pete Deemer about Yahoo!’s enterprise adoption of Scrum, Mike Cohn about User Stories, and to close the day we had an energetic presentation from Tim Dorsey of WildCard Systems about their enterprise implementation of Scrum.

Scrum Gathering 20050511

Companies using scrum: Microsoft, Sun, Siemens, State Farm, IBM, Federal Reserve Bank, Yahoo

Purpose: implement scrum

http://www.controlchaos.com/playbook.pdf

Predictions by Ken Schwaber:

33% of orgs implementing Scrum get most of the benefits – triple the initial productivity
66% will largely fail – software not that important for these orgs
Current software workload will be done by 25% of the staff
Developer will become a umbrella title for software developers – no longer specialized titles
Scrum and XP will be seen as two complimentary approaches that will start merging – may drop these names over five years

At Wildcard Systems, transition from fixed price to time and materials for clients

Bob Schatz – implemented Scrum at Primavera

Recently left Primavera now at Solstice Software

Enterprise Agile – what does it really mean?
“Enterprise”
multiple teams, same projects
multiple teams, multiple projects
implementing across an enterprise
building enterprise applications
building systems to support an enterprise
implementing across geography and cultures
Enterprise Agile is all of these and more

Implementing agile is a culture changed
culture changes are extremely difficult
transitions are different for everyone
Everyone likes change… as long as it doesn’t affect them
Two factors that facilitate faster changes
pain of doing it the old way is greater than pain of chang
new opportunity where the old way simply won’t work
Other than that
it takes strong leadership, determination, and TRUST
Learn to crawl before you think about walking

(Primavera did it all in a big chunk – WHAT SITUATIONS MADE THIS WORK?)
– amount of pain – about to start a new project – very challenging, big technical hurdles – asked about doing it with just one team – what’s the point? – whole org new the pain – let’s just get this done – didn’t want to compare apples to oranges (agile to waterfall) – decided to switch pains – bob had a management team that he spent a lot of time talking with – management team was absolutely on board – failures have come in places where management is working at cross purposes

Communication
open communications are critical in agile projects
larger, more complex projects require more communication
across organizational lines
frequent customer communications
Coordination
project managers coordinate the efforts of multiple teams
focus on team building and self-managing teams
progress and obstacles must be visible to everyone
learning and knowledge must be shared across teams
Co-location
individual teams ideally should be co-located in team rooms
the reality is that they can’t always be
get creative!
Do the best you can and compensate with technology

No silver bullet
enterprise implies complexity
implementing requires leaders, knowledge, skill, and adaptive techniques
one person will not single handedly change a company
a consultant will not change your culture for you
buying a tool will not make you instantly agile
not everyone will read the stack of books you buy them
executive sponsorship and support is needed (DISAGREE? ANYONE HAVE EXPERIENCE WITH THIS NOT BEING REQUIRED?)

Keys to Success at Primavera (100 people in dev org)
sufficient motivation to change (pain)
good coaching from outside
team rooms
town hall project meetings – like daily scrum but from reps for each team
project manager role transition
information radiators
no OT/weekend working – change perspective of managers that OT is good
test driven development
“science fair” sprint reviews
build process
rotating “Scrum Master” responsibilities (after doing scrum for 1.5 years started seeing little hierarchies in teams) – certified ScrumMasters became cross-team coaches
best team performance rewards @ end of each sprint related to performance, scrum compliance, etc.
team-based bonus component (two components focused on scrum plus teamwork)
feature budgeting – work on feature only budgeted time, if over, negotiate with PO (ESTIMATES DON’T WORK regardless of tools)
sprint defect limits (tradeoff in favor of quality)
customer Webex sprint reviews
commitment to learning!
Combination of these things reduced defects by 75% (year 1 1200 to 600 with scrum, year 2 600 to 300 with XP)

What to Expect
resistance – always resistance to change
setbacks
problems
obstacles
damaged egos
unrealistic expectations (kept implementation of Scrum quiet)
difficult personalities
lack of trust

“The Hurricane’s” System!!
Ken -> Hurricane -> disaster/destruction -> rioting -> calm -> Ken
Ken tells it like it is
people get freaked out

What you will get
well-respected motivated focused workforce
creative energetic learning environment
everyone focused on achieving goals
ability to meet commitments and be flexible
high value products
a disciplined repeatable approach to building software
cross functional teams that understand technology and business value
involved satisfied “customers”
Academia does not model cross-functional collaborative team work (e.g. No collaboration with business school)

What can you do?
have a vision and sell it
identify pain points and don’t be afraid to try something different
openly discuss behaviors and challenges
look for the “real” issues, not just what people talk about
identify champions and leverage their power (people who influence others – make sure they’re on board)
educate people outside of development and involve them in the process
brush up on your influence and negotiation skills
use the language and ceremony of agile
reward good behaviors, celebrate success
work the bad attitudes out of the system
don’t sweep them under the carpet
be patient, persistent… don’t give up!

What would you do differently
everyone makes mistakes
communication as a leader could have been better

How did you set expectations?
upper management already had low expectations
middle management was told that there were no expectations for the first few sprints

Add process/environment/team improvements to the backlog – someone has to pay the price for it. Everything goes on the backlog! Nothing is ever perfected – always changes and improvement.

Made mistake – Scrum of Scrums was institutionalized with responsibilities – but this caused power and conflict issues – eliminated this and move to town hall meetings (Scrum of Scrums as a meeting rather than an organizational structure)

Times for management feedback
sprint planning and review
special meetings (maybe triggered by observation in daily scrum)

Core of stubbornness, courage or stupidity.

Esther Derby – Panel Discussion of Agile Change: Building the Self-Organizing Enterprise

Tim Bacon – from UK – ScrumMaster and Coach
Jeff McKenna – Original Builder of Scrum
Diana Larson

Tim:
transition to XP since 2000
deal with personal and small group level
culture about how people interact – congruence between thoughts and action – values

Jeff:
1991 Scrum
Agile before that
primarily with small teams but up to 80 people
difficulty – getting people engaged – people don’t have responsibility for the things they do – power to make changes in working lives – very difficult
Diana:
culture is the stories we tell ourselves about ourselves
changing language
systems level of change – “freedom’s just another word for nothing left to lose” J. Joplin

Deb Hartmann
are there places where we shouldn’t bother trying to change?

Yes, but depends on how you like to spend your energy.

Jeff:
if entire org is saying “no” then listen, but sometimes people say “no” without knowing what they are saying “no” to
as a consultant: there are times when you say “I don’t want to do this anymore”
if motivation is there “I want to change” then it is easier

Diana:
if some say “yes”
“see where the buffalos of change have roamed before and see what kind of a trail they left” – indicators of where things might go in the future
ego involvement – significant influences who have lots of investment in the way things are can prevent change – or need someone who can move them out of the way
How do you make org change stick?
You don’t
orgs keep changing – not really a new status quo, just a breather

Tim:
you can always change starting with yourself
personal integrity and desire to go to work
sometimes need to change other people to keep integrity

Jeff:
find out what people mean by “being agile”
explore what they mean

Going from waterfall to scrum – is there a smooth transition?

Diana:
define “smooth”?
People go through change in different ways – lots of models of change
resistance can be characterized as wanting to hold onto something of value
people need to see new/better value in the destination
may be emotional
the transition in people changing is chaotic and it is hard to do smoothly
some people are not set up psychologically to make a smooth transition
can’t completely make transition roughness go away completely

Jeff:
some orgs are easier than others
some orgs have a culture of change
2nd order effect
need some success with change
gain some power to make lives better
rank and file are often pessimistic

Tim:
uncover the pain that is already there
uncover the good things

Ken Schwaber:
a few years ago Martin Fowler: not going to try help unless the org is a train wreck, without hope
now seeing large orgs investigating going agile because of agile’s successes
sitting with CEO of corp that want’s to go agile
how can I determine if this is even worth doing?
What are some yes/no questions?

Diana:
what types of change and how did they go?
What is it like when someone needs a change from facilities?
How work with HR when needs to be an adjustment?
How do the support systems support the org?
Is the org capable of making a container?

Jeff:
find out where the pain is? What is agile going to address? How is he/she thinking about it?
V.P. Of large company – 2 hours
6 what if’s suggested
kept saying couldn’t do it
left (maybe someone else could do it)

Tim:
litmus test
looking for intellectual curiosity
actively asking questions
seeing possibilities as you provide suggestions, description

Esther:
what are you willing to do to support this change?

Craig Larman:
ask CEO what do you know about agile? Pair programming
Customer in Scandinavia
successful scrum project compared to other projects
head of project leaving to go to another company
other PMs didn’t know about this successes
How do you sell internal success?

Diana:
retrospectives at the end of all projects
what are the root causes of success, not just failure
how do we spread the word?
Risk associated with having only one person lead something like Scrum
need to make explicit the job of knowledge and skills transfer to as many people as possible
e.g. Language “pairing” vs. “shadowing”
use newsletters, brown bags, etc.

Tim:
a big part of all our jobs is to sell what we do
all heard of failures from the inside, but seen as successes from the outside
need to make sure successes are seen as success from the outside
use networks of people
if we don’t have the networks, find the “connectors” (The Tipping Point)
secretaries
long-timers
bar, cafeteria

Jeff;
Guerrilla techniques
information radiators
celebrate when work gets done: use a bell
team loves the bell and gets done
other teams ask – what’s going on?

Can this be done from a grassroots level? Overallocated people, management confused. Really struggling. Wholesale change is impossible. How?

Tim:
yes

Jeff:
Pete from Yahoo! Will talk about this
warning management
team may have self-starting ability
may bring someone in – should start working on management immediately
technical side can improve team very quickly
constraint moves to management and planning
management will stop work if not ready
management can no longer blame dev for failures
can go higher in management hierarchy

Diana:
start with one team and work from there
team has to manage their boundary between themselves and the rest of the organization

Tim:
we tend to lack courage when implementing from the bottom up
courage is the most important
“be the change you want to see” – Gandhi
there is a lot of fear about change upsetting the status quo

Mike (?):
works outside of development
what are the upside risks? Success can kill you – what happens when you are successful and the org starts to think about institutionalizing Scrum? How do you take this to senior management? Expectation management? Transition and scaling? Lots of cutting of admin work – don’t need a lot of middle management to get stuff done.

Diana:
doing self-org teams for 20 years (*********************)
come up against: managers take two stances:
get worried and mess about
abdicate
BUT
role needs to change
what support do these teams need?
Put on workshops about how leadership shifts in this environment
planning going away
resource management, championing, boundary, facilitating all becomes even more important
requires professional development on part of managers

Jeff:
managers who pay attention know they have to learn and improve
always opportunities for improvement
what goes through the membrane between group and rest of org
sole job to manage membrane – 5 to 10 visitors a day
org context
boundaries change and move
new container forming outside of original group
Keep aware of org context and work with that

Tim:
Bob Schatz – managers have an identity problem
transition to leadership – have courage to have vision and lead
subtle
invite senior people to see the teams and join them
always work for these people to do in the team

Bottom up implementation – management happy, later ask about working more hours and weekends to get more work done? What about managers that want to squeeze their people?

Bob Schatz:
OT/weekends lowers quality – period.
Use that quality price to drive behavior
productivity drops because of quality problems

Tim:
find these managers and get them to propose this to the team
team that has successfully transitioned will make reasons for not doing this very very clear
team will supply questions to the manager

Jeff:
just ignore them – worked well
manager broke the team up into two pieces
long hours team velocity went down
normal hours team maintained velocity

Diana:
if question comes up because underlying belief not working enough hours
could be something else going on there – and underlying personal dynamic
could suggest other experiments

Not necessarily that somethings not working. Question about increase productivity based on hours.

Diana:
recruit someone to be team champion
that sort of question can be directed to champion

Jeff:
medical community research about long hours being bad for productivity

Tim:
analogy:
mechanistic thinking
people are machines?
Factories don’t run machines at 100% utilization
Lean Software movement
Theory of Constraints
people aren’t machines

put it on the backlog as a problem:
how to increase productivity by 25% without increasing manpower

Tim (?): manager may be asking for something realistic

..

Brian (?): what about external customer who says we’re not doing agile. How do we help our customers to adopt this? E.g. A client that has contracted for work.

Jeff:
what do you mean by customer?
Is your business taking an external stance on agile?
Boundary is the organization
can have waterfall relationship to client and work agile inside
may have waterfall embedded in law

Diana:
are you asking about influencing the culture of an industry?
Invite them in to be involved with the process as much as they can stand
might not be very much at first
someone internal must become a domain expert and act as customer proxy

Jeff:
start by inviting to monthly demos (relatively easy)
invite them to come more frequently
like teaching children
go visit customer

Tim:
changing relationship to customer is sometimes about asking them to give something up
have to articulate what they have to gain

Ian: how to reward agile teams to get the best out of them? Reward according to influence not control.

Tim:
“Punished by Rewards” – carrots can be just as damaging as sticks
fun work can be its own reward
agile makes work fun again
extrinsic rewards may be an indicator of other problems

Diana:
frequent small rewards better than large infrequent rewards
large cumulative effect
Esther:
worked with team that received huge financial bonus
bonus was nice BUT
want recognition and notice from managers at a personal level

Jeff:
rewards for goals set by someone else is a problem
e.g. Sales quota had no connection to work in field

?: Starting from top down? What are the top three pushbacks from dev org? How do you overcome them?

Diana:
manage your own expectations
imposing change is very difficult task
frame it as an invitation

Jeff:
“yet another change”

Diana:
varies from org to org depending on culture
e.g. “flavor of month – wait it out” passive resistance

Jeff:
keep working the way I always have

?:
working cross functionally is resisted very strongly
want to protect specialization
iterative may seem less efficient locally
Solve: team building, coaching, build on initial successes
First line management team has to buy in
some people will have to move out of the organization

Jeff:
do lots of educational work
find pain points before imposing solution

Ken Schwaber:
very uncomfortable
teams for X-functional
lots of releases
management questions about jobs
power prestige
get people to talk about their feelings and facilitate solutions
notice the problem and facilitate talking about problems

Tim:
fear comes from responsibility for things that were formerly hidden
now get to own solutions

?:
org change
need to paint vision of new organization
resistance comes from what needs to be given up?
Self-image might need to be given up

Diana:
territorialism
prestige
relationships

Jeff:
paradigm shift – whoop de doo
10-20% of people will not change
some people will have to leave the team

?:
Executives have reposed the question:
how do I facilitate a bottom-up

Mishkin:
key driver metric – top down

Tim:
initial response will be emotional

Diana:
Fast Company article “change or die”

Jeff:
limbic system seat of emotion
decisions are made by this system not the rational side
allow people to use much more of themselves

Roger:
inhibitor to change: the old plaster syndrome
things go wrong, put in a solution, solution is institutionalized
have to deal with all the injuries of the past

What about Some Good References for Org Culture and Change? Self-promotion is okay!
–

Tim: Fearless Change: Patterns for Introducing New Ideas
Jeff: Leading Change , The Heart of Change: Real-Life Stories of How People Change Their Organizations
Bob Schatz: Managing Transitions: Making the Most of Change
Diana: Surviving Transition

?: more about cultural changes for creating team rules.

Jeff:
take over conference rooms
build a relationship with facilities
give team both common area and privacy – gradually spend more time in common

Tim:
might be about owning tools

Jeff:
keep separate tools for email etc.
dev machines don’t even have personal logins

Brent:
Q&A session to HR people
dealing with emotional level
some who were most concerned went to HR directly

Esther: one sentence of advice:

Jeff:
Pay attention, watch observer, get awareness up

Tim:
be yourself and allow others to be self

Diana:
be patient, positive and don’t give up

Pete Deemer From Yahoo!

History @ yahoo! – founded in 1995
Show up at work and just build stuff
No cubes
Until late 2000
Can’t spend anymore
Impose control
Hired consulting firm to impose control
The waterfall for 4 years
Last September – Tobias Mayer – organized brown bag by Jeff Sutherland
Email went out
Pete attended along with 100 engineers
Two hours – blew off meetings
We all have “muscle memory” of small nimble projects that just worked
Pete invited Jeff S. to executive team meeting
The execs often do know what is going on
Potentially revolutionary
Exec team said “ya!” – method to madness that we used to have
December groundswell of engineers and executives – never happened before
Six project teams wanted to start
Esther Derby, Mike Cohn, Paul Hodgets brought in to inform
Four teams left
Deal: support in every way needed in exchange for completed training, coaching, one sprint followed religiously then choose
Scrum pilot program started in early Feb.
Tried bribing Ken, he recommended Paul Hodgets
Paul is light touch, close to teams
Mike Cohn – like a football coach
End of first sprint did survey (anonymous)
Team members and managers
90% response rate
Amazed
First sprint really tough…
but there’s something here
How much done, cooperation, quality of work life all had substantial improvement
Didn’t want to stop
Quote from manager who was sceptical “I don’t know how they did it but what those guys accomplished was remarkable.”
Word spread
More teams wanting to do this
Brought in Gabby Benefield
Head of Scrum practices
Now we have 8 teams + more in the queue
From six months so far -> 15 observations for big companies
1.start with the teams that want to use Scrum – scattered seeds of knowledge widely and watched for the seedlings – everyone on the team must be at least open to it working – skepticism is healthy
2.call it a pilot program – we’re not migrating to anything – creates air cover for the messiness – purpose is to learn the lessons – never stop being a pilot – stop when no more teams raising their hands – then examine why – teams that raise their hands have the most pain – Yahoo is classic matrix organization with functional silos – what about interaction between agile and non-agile: non-agile teams become enthusiastic about moving to agile
3.change is scary to many people, Scrum is really scary – resistance is “pre-conscious” – presented as common-sense practices that teams choose to take on – not management forcing it – all of this is about people – people change at different speeds – Scrum is like Indian food: some will love it right away, some will need to try it a few times – some of the biggest skeptics have evolved into biggest supporters – actively managed this – ground the exercise in honesty, openness and realism – gives people room to change their mind – don’t create us vs. them
4.Patience is a Virtue – err on the side of rolling out fewer teams and spending time getting it right – every team has had issues – don’t risk over-extending and having it collapse – at start many more evangelists for failure and news of failure spreads quickly – over budgeted for working through systemic issues that are made visible in teams – what is us, Us and Scrum
5.Find the middle path philosophically – scrum pragmatists – revolutionaries tend to be the purists – incredible passion – but also they can feel anxiety as transfer from guerrilla warfare against the system to being the system – how to keep the purists involved – revolutions eventually become mundane reality – people are messy, scrum is messy – no utopia where things work perfectly – pragmatists are very effective at carrying this out – but prone to compromise and corner-cutting – creative tension between purists and pragmatists
6.Set a high bar and set low expectations – force teams to take personal cost of training – very hard work, very expensive, may not work for you – people know when they are being sold – lots of pain and work moving a team to scrum
7.Scrum is hard – surfaces lots of nasty stuff – every pilot has had to deal with some big nasty issue – make sure people are prepared – emphasize this pain is scrum working not the opposite – was this problem there before, and will fixing it make things better – never had a team that said Scrum created a problem – be ready to go on a rescue mission – sometimes teams need help, can’t always solve things on their own – what kind of help? – more facilitative help but can include direct suggestions – teams need to build their muscles
8.get experienced help – mechanics simple, but still help is useful – but outside perspective can be very positive calm reassurance – fear of looking like an “ass” and being the “Scrum guy” as a leader – spot the small stuff that can be very telling – comes with experience
9.your enemy is your friend – spend the most time with the people who like scrum the least – the detractors can have much more impact in early stages – make them informally part of the team – take their problems and ask them to help fix them – some of them might have some good points – figure it out early – don’t let battle lines get drawn
10.be prepared to use guerrilla tactics to get things done – some policy/strategy stuff – but many are just little bumps in the road – e.g. Conference room assigned but had a big conference table so couldn’t stand up – tried to get table moved by facilities – got email “thanks for getting table moved out” – table disappeared one weekend – someone came in and tipped over table and moved it out – don’t know where it went
11.make good information more accessible than bad information – rumor mill will go into overdrive – email updates, brownbags, top 20 myths, FAQ – continuous flow of good info
12.find your evangelists – build a network of scrum proponents in every group and level of the organization – knowledge of reality both good and bad – able to speak with candor – including bad news – anchor since day one – if scrum is as good as it needs to be, it doesn’t really need me to defend it – individuals using it should inform the organization about the reality
1.Senior executives – need to have an advocate but have to be careful with it – with a single statement that person can set the tone – danger in getting exec too excited – can lead to top down imposition
1.Story about “Let’s Go” travel guides – every student reporter is fired every year – publisher has no power because temp work – used very scrum-like process
2.Something connected to a prior experience
13.Make the result visible – distributed results of survey to the rest of the team – this is the good, this is the bad – made people feel comfortable to enter the conversation – this is Scrum fixing itself
14.The urge to tinker is great – everyone has a way to improve scrum – some are necessary adaptations – a lot of them aren’t – e.g. We’re going to split out the eng, design and qa sprints (subtle reversion to waterfall), want SM and PO to be same person, want to use some practices – say “That’s fine” but reflect and compare – make very clear what is and what is not Scrum – say “using agile practices” – don’t let Scrum’s name get sullied by experiments that aren’t scrum – but experiments are still okay
15.Scrum will always be messy – Scrum is not about cleanliness, its about reality – people are insensitive and inconsistent – make mistakes and bad choices – Scrum makes the mess visible – if it feels too clean it may not be working – even the final product is messy – there is no utopia we will arrive at
Biggest problem:
first question: what does it stand for? What is the acronym
propose making it an acronym
Mad About You – Society for the Complete Ruination of Universal Mankind
Screwing Customers Royally with Methodology

How did Yahoo! get bamboozled by waterfall?
Accenture as experts in a time of trouble

Mike Cohn Filling your Backlog with User Stories

Tim Dorsey Wildcard Systems from Florida

SVP of performance improvement @ Wildcard
6 sigma and Lean
Brian Stallings from Citibank IT

change is often compared to a step into the dark
took four weeks to see results were much better – CEO took whole org to scrum immediately
What is the light at the end of the tunnel? Train? End of tunnel?
You need a leadership that will be the light
Vital stats
founded in 1997
move from cash to electronic payments – whitebox of gift cards
prepaid payment card services
2004 revenues 57mil 40-50% growth per yearsglobal

2000 – 700 million in transactions
2004 – 3.45 billion in transactions – 6 second response time

Now have 50 clients

12 million cards issued

Flexible Solutions – Managed for Client Success

Want to do good – but kept tripping over selves

System was a catastrophe waiting to happen – growth faster than expected

No fallback position because of growth

9 months scrumming last july 27 dev 6 qa 160 dev 60 qa now

Client feedback and employee morale – before scrum – not friendly to deal with, products always late, lots of bugs (but still best in business) – 82% of employees said they didn’t like coming to work – tonnes of overtime, multiple projects

Speaking executive language is very important to going enterprise wide

Executive support – let go SVP of Sales cause he couldn’t get with the program

Scrum:
1.process
2.technology
3.scrum teams (operational) everyone using it
4.people
5.org and infrastructure
6.client involvement
7.culture, behavior, morale
8.competitive advantage

Enterprise -wide implementation of Scrum:
1.Strategic Alignment
2.Organizational development – team building
3.Organizational analysis – metrics what is really going on?
4.Implement for Results
1.Symptom -> leap of faith -> solution

Took a baseline

Strategic Alignment (setting the course)
vision values and mission
process boundaries and accountability
goals indicators and targets
participation, buy-in and ownership
communications: structure and process
Lessons learned:
+strong executive support and review
+professional coaching and guidance
+consistent scrum practices
-WCS Culture: “get it done no matter what”
-recreate what we just threw out
-good is the enemy of great

Organizational Development (preparing the people)
team building and dynamics
roster roles and ground rules
expectations and concerns
interpersonal skills and meeting effectiveness
communications: metrics and alignment
Lessons Learned:
+strong review process
+learning organization (releases) – raising the bar means controlled release of the process improvements
+time boxed meetings
+team selection (teams initially had a team lead with 6months, a totally new scrummaster and 4 contractors)
-PO wanted to “own” the team
-lack of shared accountability (lack of collective knowledge of state of tasks)
-we’re different, “our client expects…” – clients are exposed to “dirty laundry” through the daily scrum as chickens and they love it

Organizational Analysis (looking in the mirror)
selection criteria & ROI
process and tools
clients, suppliers, products and services
resources and portfolio management
communications: available and consistent – e.g. Mandate on use of Primavera for communication
Lessons Learned:
+Utilized Primavera for Scrum Template
+Staffing Models Reflect Backlogs
+financial benefits – able to move from $150/hr for dev to $60/hr only ask 2 weeks notice to shut team down
+client involvement
– ROI responsibility
-poor forecasting of Start and Due Dates
-valuable early weeks wasted waiting for client decisions

Implementing for Results (making it happen)
scrum planning and launch (2 weeks)
product backlog and estimates
sprint planning decomposition and review
agile programming tools
communications: daily scrum meetings and burndown charts
Lessons Learned
+introduced launch checklist
+consistent backlog and decomposition format
+application code collisions
+operational bottlenecks exposed
-overall sizing estimates were poor
-didn’t require burndown charts immediately
-financial impact of a scrum team

Scrum Assessment: Radar Chart

Two week sprints all ending on the same day across the organization

What happens in two week ramp up after team formation develop backlog, interview clients, interview systems people

Stick to strictly normal working hours – teams are allowed to choose to work on the weekend but if it starts being a regular occurrence then look at why

Metrics:
focus on process metrics

---

Affiliated Promotions:

---

Please share!