stldodn 2014 agile on a shoestring
DESCRIPTION
Furthering your agile adoption efforts without huge training or tools investments by working with your most important asset, your people.TRANSCRIPT
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/
Agility is HOT right now
Attaining agility is HARD
Teams are continually asked to tighten their belts while DELIVERING on their goals
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
–noun
1. flexibility, the capacity and capability of rapidly and efficiently adapting to change.
2. ability to take advantage of opportunities while controlling risk
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
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!
Agile is NOT about doing more for less
Agile Is about doing LESS for less
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
Think Differently About Products
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
Think Differently About Practices
Well groomed backlogs
Forecasting over Promising
Daily Standups
Definition of Done
Deliver, deliver, deliver
Naval-gazing
Cost of each of these tools is $0
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!
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
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!
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
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
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!
Think Differently About Roles
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.
Owns the product vision
Prioritizes the backlog
Ultimately responsible to the end
users
NOT the team’s manager
Owns the process
Keeps the team on track
Removes impediments
Coaches the team
Also not the team’s
manager
Includes analysts, testers, coders, operations
Self-organizes to get work done
This is the team’s manager.
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
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
“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
Positivity
Uncertainty
Fear
Lies, damn lies, and statistics
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!
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
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.
“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
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!
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
In your business…
And in your people…
And of your time…
But the ROI is outstanding
Adopting agile software delivery strategy does not HAVE to be a million dollar investment
But if you have money to burn, I can help
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/
Platinum Sponsors
Silver Sponsors
Gold Sponsors
dodn14.azurewebsites.net
Quick access to conference info
Build your custom agenda
Anonymously rate the sessions you attended
Share with the Twitter-verse
