Agile has been around since 2001. Most of us have read some of the literature, or at least laughed at the caricatures.
In 2001 a bunch of consultants got together at some resort and created this manifesto.Many of them had already formed the bases of methodologies that we have heard of that accomplished basically the same thing, but differently.I think these values are interesting, but they don’t tell me what or how, - they don’t even tell me what problem we are solving.
I stole this from Scott Ambler (who now works for IBM Rational) as their “evangelist”…I think it is a concise definition of the “What” of agile – but it is devoid of the why.
If you have ever been a part of a new agile adoption on a team, you will probably recollect that there is something of a backlashOne aspect of all agile processes is that they expose information that sometimes is not pleasant to see.Productivity issues, personal agendas, competence issues are all brought to light. The question is how do we respond to this information?
The major why’s behind agile practices are improvements in value, quality predictability and productivity – The how is because the increased information flow allows us to improve our process and focus on what is important.
Sometimes I feel like our whole project management and SDLC approach to software development completely forgets that we are creating capital assets, and that the value that is instantiated in the software capabilities that we deliver is made less important by our focus onProcess and Documentation.Managing against constraints (scope, schedule, cost).Fiscal Cycles and Budgets.IT delivery can get hung up wanting to use methodology to indemnify itself against blame for not delivering sufficient or needed business value. By the time developers get requirements, the understanding of how the required capabilities actually add value to the business practitioners is often reduced to almost nothing.
We are going to play a game – Just to see if you are paying attention.Cheeseburger (or other form of lunch) will go to the winner.
This really applies to a new product or new team. Here we may start a new project but against existing products. However, sometimes products transition from one team to another (reorg?) – and we need to get established again. Iteration Zero is a way of time boxing start-up cost.
Now that our standard Java and .Net architectures support this, we should take advantage.Usually the way this works, is that within a short time of each check-in, say 15 minutes – the CI server starts a build. Team is notified of build failure. This means that check-in of code that breaks the build can be backed out, or remediated quickly so that it doesn’t impede the rest of the team, or so that some time later, we can’t figure out where things got broke.Last team I was on the rule was fix the build before you go home or bring in donuts….-- many teams attach Unit Test execution to CI build execution, so that if the build passes, it also runs all the unit tests too.
Of course this applies to new systems, but can also be used anytime we are leveraging components that are new, or connecting through new integration points. This is a way to reduce risk of unfamiliarity.This can also be done in lieu of a POC, so that you get a working “something” quickly, that is not completely throw away.
TDD or Test First have been around since the late nineties – If you write the tests before you write the code, and your tests are sufficient to determine working, then when the tests pass you are done – right – well depending on how elegant you want your code to be. If you have the tests, you can refactor to make the code design better without worrying as much about breaking the logic.
If you are doing TDD, this is really essential – a framework like jUnit or nUnit is necessary to automate the testing necessary to make you really productive.
YAGNI – You ain’tgonna need it. - don’t design for cases that are not in scope for the current (release, timebox, story) depending on your delivery vector.Satisficing – (yes this is a word) meaning just good enough and no more. Combines satisfy with suffice - Term was coined by Herbert Simon. He pointed out that human beings lack the cognitive resources to maximize: Key here is that we should not be anticipating future state in our design, other than our capacity to extend towards anticipated requirements. This assumes a low cost and risk associated with extending towards future requirements (as supported by other practices like CI, refactoring, Automated unit testing, etc).
The key take away here is that in agile, we test during each time box, as soon as a story (testable software capability) is complete. Thus we are exercising the testing skill and the development skill concurrently. The information that comes back from testing regarding the quality and usability of our software capability allows us to improve both without extending time.
Having the developers, testers and analysts (and optimally the customer) sitting in the same space, where free collaboration can occur spontaneously is a huge benefit.
We all instinctively know that the feedback that we get from actual users is way more valuable than the feedback we get from product management or testing. Business practitioners are our “real” customer. So the faster we get software capabilities in their hands, the more information we have about the value we have delivered. If they touch nothing until we get all the capabilities built, then no information comes back, and we are stuck defending whatever we did, ‘cuz there are no options left.
If I have a list of all the software capabilities that I have been asked to deliver, in a basic delivery sequence, then as we incrementally deliver these to production, the information that flows back can influence the delivery sequence for future time boxes, and releases.Requests for enhancements that are more valuable than new software capabilities (because we have new information about the business process that we have enabled) can be sequenced ahead of less valuable capabilities.This prevents the delivery of seldom or never used capabilities, while simultaneously our customer clamoring for other things.
Requirements start with a business value to be deliveredOnce we propose a software capability that delivers that business value, we need to understand how that fits in or impacts various processes, and what its usage pattern will be.The faster we deliver design and working code, the more feedback validates and elaborates our requirements.
Depending on the length of our time boxes, and the size of our team we need to plan just enough work to keep the team moving forward.If my feedback loop is short, and we can re-sequence work, then why would I plan activities that I might never complete, in great detail. This does not mean that we do not care about risk associated with some software capabilities, our concern for risk should drive the sequencing – that is we compromise between maximizing value and retiring risk in the early increments of delivery.
If my time boxes are consistent, then the metrics (how much work got completed) helps me tune my commitment along the way. If my time boxes are short (2 weeks) I have lots of time to react even on short projects (3 months or less).
The purpose of the planning game is to have business (customer) and developers interact about what is important. Planning games contemplates not only the deliver of software capabilities, but also release commitments.Cost, Risk, and Value are drivers for planning moves.
Retrospectives are valuable, but sometimes hard to manage. It is usually necessary to select one or two things to focus on, that add the most value or solve the most urgent problems identified. - like every other practice – the more frequently you do it, the faster you get good at it.Process improvement for a working team is somewhat like fixing a motorcycle while your customer is driving down blind alleys at high speed. Have any of you ever worked for Rich Houle??? Uh Huh….
Useful for measuring velocity (rate of estimated work per unit of duration) (e.g. effort days per two week sprint)Also useful because you can see velocity trending up or down over time.-- burn-ups, have the benefit (over burn-down) of being able to expose where sequencing or planning decisions have impacted scope, or where estimate revisions have materially affected the plan.
Agile practices and benefits
Agile Practices and BenefitsFor Northern Developer NetworkBy Rich Stone and Peter Schuh1
Agile• ag·ile (aj-uhl, -ahyl)adj.– 1. Characterized by quickness, lightness, and easeof movement; nimble.– 2. Mentally quick or alert: an agile mind.2
Agile Manifesto• Individuals and interactions over processesand tools• Working software over comprehensivedocumentation• Customer collaboration over contractnegotiation• Responding to change over following a plan3
Agile Software Development• An iterative and incremental (evolutionary) approachto software development• which is performed in a highly collaborative manner• by self-organizing teams within an effectivegovernance framework• with "just enough" ceremony• that produces high quality solutions• in a cost effective and timely manner• which meets the changing needs of its stakeholders.4
Agile Methodology?5XP, SCRUM, FDD, DSDM, Crystal Clear – are all agile “process frameworks” – thatrecommend a group of related practices.All come from a consulting mind-set, and all have fairly prescriptive approaches– rather than value selected approaches – so they look like a consultant with amethodology. Not that they don’t add value, but is it the value you need? Onlyyou can decide that.
Why Agile?More Value, Higher Quality,Less Risk, More Predictable,and yes, More Productive6
Simply Agile• Recognize that value is a more important driver forsoftware asset creation than schedule or cost.• Admit that we don’t/can’t know everything needed to getdone before you start so details can emerge.• Decentralize decision making to empower the productteam as much as possible, flattening team structures,replacing command and control with intense collaboration.• Exercise all your skill areas concurrently to increaseinformation flow (for the software development system) byshortening all feedback loops.• Build, Borrow, Buy automation tooling to make thingseasier, faster, more reliable.7
Agile Buzzword Bingo?First one to get four in a row wins acheeseburger!8
Agile Practices• We have a list of practices and a bingo card.• We are going to walk through a list ofpractices that are common and valuable.• If you are on a team that is doing the practicenow, put a chip on your card.• If you are not sure if you are doing it, ask.• Questions are valuable – ask away.9
Iteration ZeroSpend a time box to put delivery infrastructureand product backlog in place (devenvironment, test environment, test and buildautomation, user stories, mockups, etc)Think of it as build a road before we drive thecar.Improves Predictability10
Continuous IntegrationIntegrating small bits of completed functionalityinto the team codebase many times a day, andusing manual or automated process to ensurethat the codebase is clean after each check-in.Continuous integration aims to improve the quality,and to reduce time to deliver, by replacing thepractice of applying quality control to largerdeliverables.Increases Quality, Reduces Risk11
Walking SkeletonA Walking Skeleton is a tiny implementation of thesystem that performs a small end-to-endfunction.It need not use the final architecture, but it shouldlink together the main architectural components.The architecture and the functionality can thenevolve in parallel.Improves Productivity, Reduces Risk12
Test Driven DevelopmentTest-driven development (TDD) is a softwaredevelopment process that relies on the repetitionof a very short development cycle:first the developer writes a failing automated testcase that defines a desired improvement or newfunction,then produces code to pass that test and finallyrefactors the new code to acceptable standards.Improves Quality, Reduces Risk13
Automated Unit TestingA systemic suite of tests, coded by individualdevelopers to test at the method level, basedon restorable data, run after each successfulbuild, to provide immediate feedback on anynew code added to the system.Improves Productivity, QualityReduces Risk14
Simple DesignThis is an extension of YAGNI and satisficing (goodenough) design concepts.Dont design for the ultimate scenario, or anticipatefuture needs, design only what is needed for thecurrent story/requirement.Works best when used with other practicesincluding continuous integration, automatedbuild, refactoring, etc.Improves Productivity, Value Delivery15
Acceptance TestingWrite tests for each story (requirement) beforedevelopment (for that story) is complete.Acceptance tests are defined by the customer asthe acceptance criteria for the story.Performed as each story is completed, ratherthan at the end of a time box or immediatelyprior to release.Improves Quality, Reduces Risk16
Co-located TeamSeating the entire team in an open-spaceenvironment where conversation can beoverheard, design and analysis sessionsorganically emerge, questions can beanswered without anyone leaving their chair.Improves Productivity, Quality17
Incremental ReleasesRelease product to production as soon as youhave something of value, rather than waitingfor the entire scope of value to be complete.Moves the flow of information about value backto product team and product owner as earlyas possible.Improve Value Delivery, Reduce Risk18
Product BacklogSequenced list of features or stories that havevalue and effort estimates associated withthem.Used in all planning exercisesIncreases Value Delivery19
Emergent RequirementsAny requirements method that acknowledgesthat we dont know everything “up front”.Starting with what we know, and expecting tolearn more through design, development andfeedback from customers.Yield requirements that are independent andcan be sequenced.Improves Value, Productivity20
Emergent PlanningA form of planning, where one works top down,identifying large chunks of work and estimatesin gross to form a baseline schedule, thentakes a shorter window of time to “elaborate”the plan in more detail (focusing on the near-term deliverables), and continues over time.Improves Predictability, Reduces Risk21
Time BoxingThe time box (iteration, sprint) is the feedback ormeasurement cycle of your project.By choosing short time boxes, you increase theinformation flowing into your developmentprocess, so that genuine process improvementcan result.Requires planning through sequencing and teamcommitment of deliverables.Improve Productivity, Predictability,Reduces Risk22
Planning GameMaking sequencing (a form of prioritization) ofstories or features into a game.Designed to reduce emotions in planning.Goal: put the greatest possible value intoproduction over the life of the game.Improves Value Delivery23
RetrospectiveIn agile development retrospectives play a veryimportant role in iterative and incrementaldevelopment. At the end of every time box aretrospective is held to look for ways toimprove the process for the next time box.Improve Productivity, Reduce Risk24
Burn-up/down ChartA bar chart, or line graph, showing the passageof time on the X axis, and the remaining workestimate on the vertical axis.Useful for determining if the team is burningwork, according to a pre-determined scheduleor commitment (like within a time box)Improves Predictability25
Other Practices• The following practices were weeded out,solely on the basis of our need to restrict thesize of the BINGO card.• Just sayin’26
Blitz PlanningA single planning activity, attended by membersacross the project, that can produce a draftproduct backlog, release plan, andsequencing.Improves Predictability27
RefactoringRefactoring is the process of changing a softwaresystem in such a way that it does not alter theexternal behavior of the code yet improves itsinternal structure.When developers encounter unnecessarycomplexity in the area of code they are workingon, they can simplify and clean the code, therebypaying down technical debt.Improves Quality, Reduces Risk28
Automated DeploymentAutomated deployment of a build to a user-configured environment (for example: DEV,QA, STAGE, PROD) enables early testing of thesystem in production-like environments anddrastically reduces the possibility formigration-based errors.Reduces Risk29
Solution SheetsA simplified analysis document that articulatesthe essential requirements, business logicand/or design of a user story prior to itsdevelopment.Improves Predictability30
Kanban BoardA visual, work queue-based approach toplanning and tracking that:(1) puts the teams value stream at the center ofthe development process and(2) easily communicates prioritization andongoing activity across the team and itsstakeholders.Improves Productivity, Value Delivery31
Effort EstimatesEstimating effort instead of duration:- not when will I have this done, but how muchof my time will I spend on this specific work.- allows work to be split across team members,and estimates to calculate mathematically.- allows the development of a cost estimate anda scheduleImproves Predictability, Reduces Risk32
On Site CustomerA practice that engenders a highly-collaborativeenvironment with speedy turn-around times,constant adjustment to user-driven feedbackand low documentation. It costs thededication of a "super user" and the co-location of that individual with the deliveryteam.Improves Productivity, Value Delivery33
User StoriesA lightweight, INVEST-based approach to projectfeatures/requirements, making themIndependent, Negotiable, Valuable,Estimatable, Small, Testable.Improves Value, Productivity34
Daily StandA brief daily whole team meeting (15 min orless) focused on a simplified status of work inprogress or recently completed.Helps to identify issues and obstacles, beforeany commitments are impacted.Improves Productivity, Reduces Risk35
Thank YouThanks for playing along.We hope that you were able to glean somevaluable nuggets of information.We hope that you will consideradopting/adapting some of the practicespresented here for your team’s benefit.The spreadsheet attached to the invite also haslinks to external (to Northern) informationresources regarding Agile Practices36