Furthering your agile adoption efforts without huge training or tools investments by working with your most important asset, your people.

2. Polaris Solutions ALM Practice Mgr since Jan ‘12
Been in the software industry since 1999
Runs the Chicago ALM User Group
ALM MVP, PSM, PSD
Has a *possibly* unhealthy love of Halloween
Shameless self promotion
Polaris Solutions- http://www.polarissolutions.com/
Chicago Visual Studio ALM User Group - http://www.chicagoalmug.org/
Twitter: @OakParkGirl, @ChicagoALM, @TeamPolaris
Blog - http://www.tfswhisperer.com/

3. http://polarissolutions.com

4. Agility is HOT right now
Attaining agility is HARD
Teams are continually asked to
tighten their belts while
DELIVERING on their goals

5. Working more HOURS is not the answer
“Working faster” is not based on reality
Sacrificing QUALITY is not the answer
Hiring more PEOPLE may help
Ultimately we have to spend time on the RIGHT things

6. –noun
1. flexibility, the capacity and capability of rapidly and
efficiently adapting to change.
2. ability to take advantage of opportunities while
controlling risk

7. Agile processes are NOT:
Bound to a particular set of tools
Only for small teams
Only for developers
Only for green field projects
Unstructured
Undisciplined
Undocumented

8. Agility isn’t just about being fast.
Crap delivered quickly, and successfully, is still crap!
Agility isn’t about getting more done.
Getting more done is only useful if you’re getting the right
things done. Are you?
Being “good at agile” isn’t enough either…
The goal of organizational agility isn’t to be good at practicing
agile, it’s to deliver the RIGHT products at the RIGHT time!

9. Agile is NOT about doing more for less
Agile Is about doing LESS for less

10. Rethinking your product strategy
A more open and transparent culture
Getting buy-in from everyone. EVERYONE.
Even the CIO
Even the PMO
Even finance
Training and coaching, and not just on process
Lastly, and somewhat optional, find ALM tools to support your process

11. Think Differently About Products

12. http://ow.ly/i/659WS/original

13. You will have to rethink how you build applications, and it will
probably suck, a lot, while you’re figuring it all out.
Assume you will deliver every iteration
Everything (almost) is a component
You may have to write throw away code
You will have to rethink deployment strategies
You really do have to actively work with the business and
end users

14. Think Differently About Practices

15. Well groomed backlogs
Forecasting over Promising
Daily Standups
Definition of Done
Deliver, deliver, deliver
Naval-gazing
Cost of each of these tools is $0

16. As accurate as a traditional Project Plan with a fraction of the
effort
Monitors the entire project, possibly the portfolio, in real-time
Prioritized by “the business” and flexible
It’s a wish-list, not a promise
Groom them often to ensure you are always focusing on the
RIGHT things!

17. Uses story points to break the taskmaster mindset and DO NOT RAT-HOLE
Remember that building and testing software is an art AND a science
Forecasts are NOT promises. Do not let this one slide!
If a backlog item cannot be delivered in a single iteration, it is too big to
estimate with any degree of confidence

18. The software team’s chance to level set and regroup on goals
Time to ask for help, raise concerns, uncover collisions, dependencies, and inconsistencies.
Questions to think about before you show up:
What did you do yesterday?
What are you doing today?
What are your impediments?
Focus should always be on progress towards Sprint goal, not status!

19. Definition:
What does “DONE” really mean?
Defined by the entire software development team (not just coders)
Should be an auditable checklist
Should evolve as the project advances.
Example:
Source code committed on server
Unit tests written and green
Code review completed (or pair-programmed)
User acceptance tests written, executed, passed
How-to-Demo verified before presentation to Product Owner

20. Call it whatever you need to - Product Iteration / Sprint / Cycle /
Phase
Length should be determined by the entire team
2 - 3 weeks ideal, but do what works best for the team
Your GOAL is to potentially release working software of value to
end users every iteration

21. Held at the end of an iteration. EVERY iteration
Discuss lessons learned, celebrate successes
Each team member answers the following:
What worked well for us?
What did not work well for us?
What actions can we take to improve our process going
forward?
Write your issues down, be accountable for them
Get out of the office if you can!

22. Think Differently About Roles

23. CEO = Chief Enabling Officer
Executive sponsors are CRITICAL
to the success of an agile team
Their buy-in, or lack thereof, can
make or break a software project,
particularly an agile one.

24. Owns the product vision
Prioritizes the backlog
Ultimately responsible to the end
users
NOT the team’s manager

25. Owns the process
Keeps the team on track
Removes impediments
Coaches the team
Also not the team’s
manager

26. Includes analysts, testers, coders, operations
Self-organizes to get work done
This is the team’s manager.

27. Traditional project managers attend meetings
and babysit project plans are responsible for
managing scope, cost, quality, personnel,
communication, risk, procurement and more.
Agile project management:
Task assignment and day-to-day decisions revert to
the team
Scope and schedule tradeoff goes to the product
owner
Quality becomes a responsibility of everyone

28. May be internal or external to
the organization
End users are the litmus test
of the value of any delivered
software
Projects that do not heavily
involve users up front often fail

29. “People get weird when companies start talking about
getting more agile” ~Ben Day
People hate change
People fear change
Most process problems are really people problems

30. Positivity
Uncertainty
Fear
Lies, damn lies, and statistics

31. Accept failure as inevitable, learn from it, move on
Get past change being a defect (bug isn’t a “dirty word”)
Occasionally, stop and take stock of where you are
If you don’t like what you have now, change it!

32. Writing software is HARD
Customers are going to change their minds
Wishing doesn’t make it so
Gripping tighter on a plan also does not make it so
Software ALWAYS gets more complex once you start

34. Your team is afraid of you
Middle managers are afraid of upper level managers
People are terrified of being wrong. Terrified.
Make it OK to be “wrong”
You need to make it ok for your teams to tell you that
you are wrong.

36. “I’m 90% done with my task.”
“I’m STILL 90% done with my task.”
Don’t cook the books
Avoid the overhead of communicating two visions
Focus on your Definition of Done. It’s DONE or it isn’t.
Incomplete or untested software doesn’t count

37. Whiteboards, sticky notes, and notebooks can
suffice
ALM tools are spectacular at recording important
data, generating reports, and enabling
communication
ALM tools can add the automation necessary to
deliver software quickly while respecting your
process
ALM tools vary from free to OMG expensive
Choose the right tool for the right job!

38. Stop: Pause, inspect, adapt
Collaborate: teams should hold daily
stand-ups regardless of their process
Listen: Pay attention to the team,
investigate “smells”, change things that
suck for them

39. In your business…
And in your people…
And of your time…
But the ROI is outstanding

40. Adopting agile software delivery
strategy does not HAVE to be a
million dollar investment
But if you have money to burn, I
can help 

41. Agile manifesto: http://agilemanifesto.org/
Scrum Guide (Scrum.org): http://www.scrumguides.org/
DTDPS Agile Deployment Program: http://bit.ly/1xmOm2l
Angela’s Slide decks: http://www.slideshare.net/angelabinkowski
Angela’s blog: http://www.tfswhisperer.com/

42. Platinum
Sponsors
Silver Sponsors
Gold
Sponsors

43. dodn14.azurewebsites.net
Quick access to conference info
Build your custom agenda
Anonymously rate the sessions you attended
Share with the Twitter-verse