12.07.2015 Views

Planning & Tracking at the - ASPE – SDLC Training

Planning & Tracking at the - ASPE – SDLC Training

Planning & Tracking at the - ASPE – SDLC Training

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>ASPE</strong> Technologywww.aspetech.com1-877-800-5221 Toll-FreeRel<strong>at</strong>ed <strong>Training</strong> Courses:• Agile Project Management• Agile Software Development• Agile & High Speed Software Testing Techniques• The ScrumMaster Certific<strong>at</strong>ion Workshop**There are no PMI PDU’s for this web seminar.


<strong>Planning</strong> & <strong>Tracking</strong> aSoftware Project <strong>at</strong> <strong>the</strong> “Right”LevelWh<strong>at</strong> can we learn from <strong>the</strong> AgileMethodologies?Robert L. GalenRGalen Consulting Group, LLCwww.rgalenrgalen.com


Outline• Many factors effect our planning “level”• Attributes of planning too low and too high• Potential examples of “Just Right”• Extreme Programming• Scrum• Endgames• Common <strong>the</strong>mes and wh<strong>at</strong> does “Just Right” look like?• Conclusions / Q&ACopyright © 2006 RGalen ConsultingJune 2006 Group, LLC3


Goals• Given th<strong>at</strong> <strong>–</strong>• Estim<strong>at</strong>ing, planning and tracking are hard• Businesses are challenged, speed is paramount and change isconstant• There is no “Right” answer, but more so “It Depends”• Sensitize you to your planning “levels” and overalleffectiveness• Share “agile options” for you to think about, investig<strong>at</strong>eand try for yourselfCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC4


Too High, Too Low andAssessing WhichCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC5


Factors Influencing Your<strong>Planning</strong> “Level”• Experience and skill of <strong>the</strong> team, planning staff andmanagement staff• Size of <strong>the</strong> team• Distribution of <strong>the</strong> team (geographic, contractor)• Funding limit<strong>at</strong>ions (people, tools, training)• Company history and culture• Organiz<strong>at</strong>ion structure• Corpor<strong>at</strong>e processes and methods• Who is “bre<strong>at</strong>hing” down your neck ☺Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC6


Characteristics of <strong>Planning</strong> <strong>at</strong> TooLow a Level (Trees)• Spend a tremendous amount of time planning• Trying to capture exact requirements• Exhaustive risk analysis• Overuse of historical d<strong>at</strong>a• Small tasks, less than 1 day dur<strong>at</strong>ion• Mini milestones, less than 2-323 days dur<strong>at</strong>ion• Typically tries to capture <strong>the</strong> entire plan, short and longerterm and <strong>at</strong> a very deep level• Overreaction to neg<strong>at</strong>ive events, “deep” analysis• Synonymous with “Analysis Paralysis”Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC7


Characteristics of <strong>Tracking</strong> <strong>at</strong> TooLow a Level (cont.)• St<strong>at</strong>us reports <strong>–</strong> daily upd<strong>at</strong>es, written or verbal• Overly reactive to daily changes <strong>–</strong> normal ebb and flowof a project• Upd<strong>at</strong>ing all task inform<strong>at</strong>ion from everyone on a weekor less granularity• Excessive action tracking, many daily meetings• Personnel interactions <strong>–</strong> several times a day forinformal st<strong>at</strong>us g<strong>at</strong>heringCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC8


Imagery• Japanese software development team• Large room• Long row of connected desk space• 2 rows of developers facing one ano<strong>the</strong>r• Manager <strong>at</strong> <strong>the</strong> head of <strong>the</strong> table• Every action monitored, every task reviewed, everyresource “managed” <strong>–</strong> every minute of <strong>the</strong> dayCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC9


Potential Problems• You’re managing <strong>the</strong> details, but are you going to besuccessful?• Missing critical parts of <strong>the</strong> “big picture”• Missing <strong>the</strong> important bits• Get a false sense of security (unknowns risks, technicalchallenge, defect r<strong>at</strong>es, etc,) Change IS constant!• Not leveraging <strong>the</strong> skills, teamwork and collabor<strong>at</strong>ivepower of <strong>the</strong> team• Morale of <strong>the</strong> team effected by micromanagementCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC10


Characteristics of <strong>Planning</strong> <strong>at</strong> TooHigh a Level (Forest)• Spend too little time planning• Simply put a framework of loose goals toge<strong>the</strong>r• Or worst of all, taking <strong>the</strong> plan (d<strong>at</strong>e / feasibility) from<strong>the</strong> “Business” or Sr. Management• Attitude of <strong>–</strong> We need to be building it…now!• No risk analysis• No project manager, <strong>the</strong> “managers” should be able tomanage thingsCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC11


Characteristics of <strong>Tracking</strong> <strong>at</strong> TooHigh a Level (cont.)• Little / No st<strong>at</strong>us reporting• Little / No reaction to changing project landscape• Little upd<strong>at</strong>ing of progress to plan / schedule• No action tracking and little follow-up• Little team interactions, everyone simply on <strong>the</strong>ir own <strong>–</strong>• Ei<strong>the</strong>r within functional groups• Cross functional groups• As a teamCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC12


Imagery• CEO of a small company building financial tradingsystems• 30 years <strong>at</strong> IBM, reput<strong>at</strong>ion as a “deal” maker• Priv<strong>at</strong>e meetings in a darkened office over drinks(coffee) and cigars (imaginary)• A game of “chicken” to give a d<strong>at</strong>e, th<strong>at</strong> <strong>the</strong>n becomes<strong>the</strong> str<strong>at</strong>egy and “plan of record”• Team had no time to prepare a plan, no buy-in and nofeasibility, no detail and no time for it• Afraid of <strong>the</strong> truth and execution by faithCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC13


Potential Problems• You’re not managing anything, up to <strong>the</strong> team to“figure it out”• Unknown sense of security <strong>–</strong> no risk management <strong>–</strong> nostr<strong>at</strong>egy <strong>–</strong> no roadmap• Not leveraging <strong>the</strong> skills, teamwork and collabor<strong>at</strong>ivepower of <strong>the</strong> team• Morale of <strong>the</strong> team. Where IS <strong>the</strong> plan anyway? WhereARE we going?• Overall probability of success?Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC14


Usually Things Aren’t So Clear…• In most cases, planning & tracking levels vary gre<strong>at</strong>ly by• Sr. leadership style• Functional manager style• Project management m<strong>at</strong>urity level and processes• The st<strong>at</strong>e of <strong>the</strong> project• Amount of pressure• It’s important to note your overall project “level” andto understand <strong>the</strong> variance• Remember <strong>–</strong> it’s all about achieving a properBALANCE!Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC15


Your Level Assessment• Good to assess where you are from a planning andtracking “level” perspective <strong>–</strong>• Generally, where are you currently <strong>–</strong> over, under or just right• Characterize your planning (methods, artifacts)• How do you track progress?• Gain <strong>the</strong> view from your teams and stakeholders, wh<strong>at</strong> do<strong>the</strong>y think?• Continuously evalu<strong>at</strong>e “why” you do wh<strong>at</strong> you do. Wh<strong>at</strong> are<strong>the</strong> driving forces for your planning efforts? And are youbeing effective?• I think it’s prudent to frequently assess your level with yourleaders, managers and your team.Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC16


Taking a look <strong>at</strong> “Agile” methodsCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC17


Agile “Extremes”• I’ve presented variables th<strong>at</strong> should influence yourplanning levels and examples of <strong>the</strong> High/Lowextremes• There are 7 Agile Methods loosely rel<strong>at</strong>ed by basicprinciples <strong>–</strong> Agile Alliance / Agile Manifesto• Let’s examine 3 th<strong>at</strong> approach <strong>the</strong> “Right” level <strong>–</strong>• Extreme Programming <strong>–</strong> XP (Beck)• Scrum (Schwaber(& Beedle)• Endgame management (Galen)Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC18


Extreme Programming• Introduced by Kent Beck in 2000 book <strong>–</strong> XP Explained• Based on Chrysler C3 HR system project• Small teams, pair programming, highly iter<strong>at</strong>ive , littleplanning, few documents, highly customer focused• Leading agile method, tremendous developerenthusiasm & synergy• Stories• Mini use cases / requirements / tasks <strong>–</strong> 3x5 card per story• Derived and prioritized with customerCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC19


Extreme Programming (cont.)• Effort Estim<strong>at</strong>ion• Technical team estim<strong>at</strong>es <strong>the</strong> effort• Collabor<strong>at</strong>ive, team based view of history, allows over/underestim<strong>at</strong>ion• Recommend ordering and identify technical risks• <strong>Planning</strong> game• Customer selection of stories and ordering• Team signs-up for work• End iter<strong>at</strong>ion progress reviews, carry forward to next gameCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC20


Extreme Programming (cont.)• 1-33 week iter<strong>at</strong>ions• Very small iter<strong>at</strong>ions for feedback <strong>–</strong> to customer, team andinto next planning game• Ability to quickly adapt to changes• <strong>Tracking</strong>• Daily stand up meetings with team (customer)• “Tracker” collects team progress• Nei<strong>the</strong>r off nor on track, you just “are” where you are• Always complete <strong>the</strong> iter<strong>at</strong>ion! Adjustments made <strong>at</strong> iter<strong>at</strong>ionend <strong>–</strong> next planning gameCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC21


Scrum• First described by Ken Schwaber in 1995 paper• Book published in 2001• Applied to hundreds of projects• View it as an “Agile PM wrapper” for software projects• Product Backlog (list)• Overall product / project work for <strong>the</strong> team• Prioritized list of functions, fe<strong>at</strong>ures, technologies andbusiness goals• Customer driven content and priorityCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC22


Scrum (cont.)• 30 Day Sprint• Driven by sprint goal & uninterrupted• Can change functionality as long as meeting sprint goal• Backlog upd<strong>at</strong>ed with st<strong>at</strong>us on progress• Sprint <strong>Planning</strong>• Define a sprint goal• Map backlog “targets” to <strong>the</strong> sprint goal <strong>–</strong> should align inpriority order• Factor in capabilities (past performance) of <strong>the</strong> teamCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC23


Scrum (cont.)• Daily Scrum (meeting)• Led by Scrum Master• Focused and brief, mand<strong>at</strong>ory <strong>at</strong>tendance, every teammember (chickens) speaks, observers (pigs) do not• Everyone answers 3 questions:• Wh<strong>at</strong> have you done since last scrum?• Wh<strong>at</strong> do you plan to do till <strong>the</strong> next scrum?• Any impediments to your work?Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC24


Endgames• Mastering <strong>the</strong> Endgame in Software Projects, l<strong>at</strong>e 2003public<strong>at</strong>ion• Endgame period <strong>–</strong> from first release for testing toproduct release• Triage & repair planning, defect management &metrics, team dynamics and endgame planning• Change Control Guidelines• Code Freeze “stages” <strong>–</strong> reduction in number of accepted changes• Change reduction milestones, linked to testing str<strong>at</strong>egyCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC25


Endgames (cont.)• LW-CCB (Change Control Board / mechanism)• Defect repairs priority ordered w/Customer “in mind”• Scheduling / timing of <strong>the</strong> repairs• Flexibility in <strong>the</strong> repairs (workarounds, partial repairs)• Meet weekly <strong>–</strong> daily, depending on defect arrival r<strong>at</strong>es• Endgame <strong>Planning</strong>• Endgame Release Framework (workflow, milestones, changereduction)• Well defined release criteria <strong>–</strong> goals• Endgame release iter<strong>at</strong>ions, every 1-212 weeksCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC26


Endgames (cont.)• Daily Meetings• 30 minute, morning, standup• Entire endgame team• Discuss st<strong>at</strong>us, impediments• Action lists, Top 10 issuesCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC27


Wh<strong>at</strong> are some of <strong>the</strong> common<strong>the</strong>mes?Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC28


Common Themes• Team Collabor<strong>at</strong>ion• Daily Meetings (st<strong>at</strong>us, progress, issues, impediments)• Particip<strong>at</strong>e in work sizing and sign-up for work• Directly with each o<strong>the</strong>r, management and customers• Short, Iter<strong>at</strong>ive Cycles• Short, controlled work bursts• Continuous feedback• Quick mistakes and quick adjustmentsCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC29


Common Themes (cont.)• Handling Change• Anticip<strong>at</strong>es and adapts to change• Manages th<strong>at</strong> change from a “people impact” perspective. Infact, engages <strong>the</strong> team in handling change• Controlled Work• Focused on short term work orchestr<strong>at</strong>ion• Long term dict<strong>at</strong>ed by short term progress <strong>–</strong> simply goals• Team controls workflow (pace, amount, dur<strong>at</strong>ion)Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC30


Common Themes (cont.)• Customer “Connection”• In ordering work• In determining how to handle problem trade-offs• In visibility to work performance <strong>–</strong> output, problem analysisand adjustmentsCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC31


Getting to <strong>the</strong> point <strong>–</strong>Wh<strong>at</strong> IS <strong>the</strong> “Right” level?Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC32


<strong>Planning</strong> & <strong>Tracking</strong> <strong>at</strong> <strong>the</strong>“Right” Level• I think <strong>the</strong> Agile methods have discovered a powerfulset of <strong>at</strong>tributes th<strong>at</strong> are <strong>–</strong>• People and team centered• Linked to <strong>the</strong> customer (goals, decisions, work) Really!• Highly iter<strong>at</strong>ive• Focused towards lightweight requirements, document<strong>at</strong>ion,planning, architecture, … virtually everything. The productbeing <strong>the</strong> key artifact!• Highly adaptive and extremely tolerant of change• Attributes th<strong>at</strong> you can use to rebalance your projectplanning and tracking levelsCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC33


<strong>Planning</strong> & <strong>Tracking</strong> <strong>at</strong> <strong>the</strong>“Right” Level (cont.)• Connect to your team• Team work planning sessions <strong>–</strong> feasibility & buy-in• Group st<strong>at</strong>us meetings <strong>–</strong> peer accountability• Problem detection, change detection & adjustments• Plan your work iter<strong>at</strong>ively• List of small, focused and prioritized work <strong>–</strong> stories, defects,backlog• Short iter<strong>at</strong>ions (1 day, 1-313 weeks, 30 days) for feedback• Short term details, longer term goals and intentionsCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC34


<strong>Planning</strong> & <strong>Tracking</strong> <strong>at</strong> <strong>the</strong>“Right” Level (cont.)• A daily meeting is powerful mechanism for• Proper team collabor<strong>at</strong>ion and function• G<strong>at</strong>hering st<strong>at</strong>us and tracking progress from <strong>the</strong> team• Understanding challenges and making adjustments• Connect to your customer• Member of <strong>the</strong> team, particip<strong>at</strong>e in daily meetings, a truepartner!• Direct evolution of work• Engaged in all decision making <strong>–</strong> organizing work priority,problem analysis, work/schedule adjustmentsCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC35


So…Any QuestionsThe resulting ideas are <strong>the</strong> simplest planning ideas we could thinkof th<strong>at</strong> could possibly work. But above all, remember all <strong>the</strong>planning techniques in <strong>the</strong> world, including <strong>the</strong>se, can’t save you ifyou forget th<strong>at</strong> software is built by human beings. In <strong>the</strong> end keep<strong>the</strong> human beings focused, happy and motiv<strong>at</strong>ed and <strong>the</strong>y willdeliver.-- Kent Beck & Martin Fowler from <strong>Planning</strong> XPCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC36


References• Auer, Ken, “Extreme Case Studies: How Extreme Do You Need to Be?” ” present<strong>at</strong>ionfrom RTP SPIN Meeting available from - www.rolemodelsoftwarerolemodelsoftware.com• Beck, Kent, “Extreme Programming Explained <strong>–</strong> Embrace Change”, Addison Wesley,(2000)• Beck, Kent and Fowler, Martin, “<strong>Planning</strong> Extreme Programming”, Addison AWesley,(2001)• DeMarco, , Tom and Lister, Timothy, "Peopleware"- Productive Projects and Teams",Dorset House Publishing, (1999, 1987)• Galen, Bob “Software Endgames <strong>–</strong> Controlling Mastering <strong>the</strong> Software ProjectEndgame”, Dorset House Publishing, (l<strong>at</strong>e 2003 <strong>–</strong> early 2004)• Hohmann, , Luke, "Journey of <strong>the</strong> Software Professional - A Sociology of SoftwareDevelopment", Prentice Hall, (1997)• IEEE Software May/June 2003, Extreme Programming focused issue• Schwaber, , Ken and Beedle, , Mike, “Agile Software Development with Scrum”, PrenticeHall Publishing, (2002)• www.agilealliance.orgwww.extremeprogramming.org• www.controlchaos.comhttp://crystalmethodologies.orgCopyright © 2006 RGalen ConsultingJune 2006 Group, LLC37


Contact InfoRobert GalenRGalen Consulting Group,L.L.C.PO Box 865, Cary, NC27512919-272272-0719www.rgalen.combob@rgalenrgalen.comSoftware Endgames: Elimin<strong>at</strong>ing Defects, ControllingChange, and <strong>the</strong> Countdown to On-Time Deliverypublished by Dorset House in Spring 2005.www.rgalen.com for order info, misc. rel<strong>at</strong>edpresent<strong>at</strong>ions, and papers.Copyright © 2006 RGalen ConsultingJune 2006 Group, LLC38

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!