Financial Peace for a Unitarian youth group?

I’m an adult volunteer at our churches’ youth group, and I’ve been thinking for a while that it’d be really cool if I could find a way to pass along some of Dave‘s money advice to them, to (hopefully) save them some of the grief Jennie and I are dealing with. I knew he had something called “Financial Peace Junior“, but it turns out that it’s aimed at elementary-aged kids (our youth group is junior high and high school, plus one college student).

I’ve poked around Dave’s site before, looking for curricula for different ages, and on one of my searches a few weeks ago, I ran across “Financial Peace for the Next Generation“, which is aimed at the right age group — but it’s meant to be taught in schools, where you see the kids every day, and it looks like an entire-semester class. Not the best choice for a youth group that meets once a week.

Well, I don’t know if this is something new, or if I just didn’t manage to run across it before, but today I started poking around the site and found “No Matter What“, which is specifically designed for church youth groups. It’s a 7-week class, and designed for a one-hour timeslot. The teacher’s kit costs $100, which our group could probably find. Perfect!

I talked to Cheryll, our youth-group coordinator, about it tonight, and she suggested that I bring it up when the youth leaders meet at the end of this month. She also asked if I’d be willing to teach the class, and I said you bet. Jennie also wants to help, work-schedule permitting.

The only hitch I see so far (aside from this being the first class I’ll actually teach without Cheryll’s help) is that “No Matter What” is designed for church youth groups — by which they mean, Christian youth groups (they’re apparently of the “what other churches are there?” school of thought). Jennie and I have been taking Dave’s “Financial Peace University” class, and while he quotes the Bible and talks about God occasionally, it’s not enough to bother either of us. But I suspect that “No Matter What” will push that aspect a little (or a lot) more, and our group is feisty enough that I’m afraid that might turn them off to it. From the promo materials I’ve looked through so far, it looks like the Christian bent may be pretty strong (among other things, they advise the leaders to “pray for your youth specifically to receive [the] lesson” and to “Make sure your teens understand that the only way to true Financial Peace is to walk daily with the Prince of Peace, Jesus Christ”).

But what really matters is how it comes across in the videos, and I won’t really know that until we order the kit. And even if it turns out that the presentation won’t fly with our youth, we can probably repurpose the content and ad-lib our own curriculum if we need to. (Scary though the prospect is. I’ve never taught any sort of class yet — OWL won’t start until January. This class probably couldn’t start until then, either. Though I’m not sure how I could be teaching both OWL and No Matter What during the same timeslot…)

At any rate, I suspect there may be some other Unitarians who are interested in this curriculum (and I couldn’t find any other pages talking about Dave Ramsey and No Matter What from a Unitarian perspective). So I’ll be sure to keep y’all posted on how it goes.

Leap of Faith

We’re doing it. We’re really doing it. We’re finally getting our money under control.

The budget saved our necks last week, when Jennie’s employer screwed up the entire company payroll and nobody got paid. (No, they haven’t fixed it yet.) We had to have an emergency budget meeting to figure out what we would do if her income stopped for the foreseeable future. Hopefully it won’t come to that, but that’s what we had to plan for.

We sat down to hack and scribble and hammer out a new budget. One that included the stuff we’d already paid, plus all the stuff we still needed to pay, and without Jennie’s income. And we got the first half of the month done, and it worked. It didn’t include everything we wanted it to, of course, but it covered food, shelter, transportation, utilities, insurance. It fit. I can’t tell you how that feels — to already be on as thin a budget as you think you can manage, and then have to cut some more, and do it, and have it work. I’m really starting to believe in this written-budget thing in a big way — in the past when something like this came up, we’d just shrug helplessly, say “I guess we’ll just eat every other week,” and go borrow some more money. But there’s something about writing it down, and doing it together, and committing to it in advance, that starts to bend the laws of physics.

I’m serious. We should not be able to cut this much out of our spending. I know; we’ve tried many times. And yet, we’ve done it twice since we started the written budget — once last month when we had to take Tycho to the vet, and then this month after the payroll debacle. We’ve been doing the impossible.

So we were sitting there, looking at that budget. The first half was re-done so it worked; it was time to move on to my second paycheck’s worth of income for the month.

One of the things we’d had in our original (pre-debacle) November budget was $100 to save toward our emergency fund. In the past, when things got tight, that would’ve been one of the first things to go; after all, what good is money in the bank if we don’t have a roof over our heads?

But I thought about Dave saying you have to pay yourself first. I thought about how much longer it would take us to get out of debt if we kept cutting things like the emergency fund, month after month. And I looked at the first half of our new November budget, the impossible already come to pass.

And I took a deep breath, and a leap of faith. And I said, “Let’s start by putting that $100 in for the emergency fund.”

And we did. And then — only then — we started filling in the rest.

And. It. Worked.

It worked. I still can’t quite believe it.

We won’t have enough to pay everybody, or to save up for everything that’s coming up. We won’t get to go see the new Harry Potter movie when it comes out. I doubt anyone will be getting any Christmas presents from us this year. But we’ll have food, and cat litter, and gas, and we’re paying the mortgage and the utilities and even most of our debt payments. We’ll have enough to pay the car registration next month. And $100 is going into the emergency fund.

I’ve often said that I don’t know whether I believe in God, but I do believe in faith. Faith in God, faith in a friendship (that one in particular), faith in yourself. Faith can move mountains. It can bring strength. It can change lives.

It is also, in the words of Mark Twain, “believing what you know ain’t so.”

What we’re trying to do — it’s impossible. But month by month, week by week, I’m seeing the impossible happen.

We’re going to get by. We’re going to get our emergency fund. And then we’re going Goober-intense on getting out of debt, so we never have to go through this again.

And we are never going into debt again. Not even for a car. Not even for a house.

We can do it. I’ve already seen it starting.

And I have faith.

So is disavowal going to become an annual ritual?

Sigh.

Anybody remember a little flap last year, over the beta license agreement for Diamondback?

Well, apparently nobody at Borland remembers it, because nobody actually fixed it. From section 6 of this year’s beta license agreement:

6. CONFIDENTIALITY. You acknowledge that the Product including its existence and features, and related information remains a confidential trade secret of Borland. You agree to hold this information in confidence, not disclose it to any person, and not use it for any purpose other than the use and operation of the Product as permitted under this License.

Look familiar?

Now, you know I’m going to install it anyway; you know us geeks and our toys. But think I’m allowed to be a little grumpy about it. Didn’t they fix this once already?

So anyway. By the time you read this, I will grumpily deny that I know anything about a new version of Delphi that might or might not be coming out. I don’t know anything about all this stuff I’ve been blogging about since the conference started. As far as I know, Borland isn’t coming out with another version of Delphi this year. And no, that isn’t a DVD in my pocket; I’m just happy to see you.

In fact, I have no idea why I just wrote this post. I don’t know anything about it.

(Unless, by chance, Mr. Swindell wants to fix it again…)

Closing session

  • Started on Tuesday with a surprise: a new CEO
    • Developer guy
    • Loves developers
    • Told everyone developers rule the world
    • Video on BDN
  • Will put up JBuilder and Delphi demos as well
  • Tempo – IT management and governance
  • “Project Maia” – Requirements engineering: turning Word-based requirements into something developers can actually use
  • Getting the external forces under control
  • Spirit of Delphi award: nominated & voted on by Delphi development team to a member of the community who eats, breathes, sleeps and bleeds Delphi, is active in the community, newsgroups, magazine articles, supermarkets.
    • This year: Pierre le Riche (developer of the FastMM memory manager)
  • Borland Developer Network (launched as beta in 1999 – still beta)
  • GetPublished
  • Conference proceedings online – http://bdn.borland.com/devcon05

Delphi Design Patterns

Delphi Design Patterns

Marco Cantù

 

We have some interesting IDE builds floating around… Marco’s title bar says “Borland Developer Studio 2010”. At one point when he was having some problems with the IDE, he said, “Well, it’s an early beta.”

 

  • What is a pattern?
  • Sample GoF patterns
    • Implemented with some creativity
    • Applied to “everyday visual” code
  • Delphi 2006 and patterns

Goals of this talk

  • Overview of patterns in OOP
  • Explore a number of classic patterns from the GoF book
    • from the Delphi language perspective (which matters – some of the creational patterns, for example, aren’t necessary in Delphi)
    • providing some implementation samples

What are patterns?

  • Capture similarities in repeated building blocks: design solutions, not actual code
  • GoF book
  • Pattern layout: name, problem, solution, consequences
    • The code is there as a hint, not very important. These are design patterns, not code patterns.

Goals of Patterns

  • Better OOP
    • Many patterns promote loose coupling -> more flexibility
    • “Think before you code” approach
  • Better communication
    • Pattern names are very relevant
  • RAD shines but…
    • As apps grow, you need a better infrastructure, not just the plain VCL

Prototype pattern

  • Create a new object of the same kind of another object you have at hand
  • In Delphi you can implement a Prototype using:
    • Class references
      • If you don’t need to copy the data, you can just do Object.ClassType.Create
      • If you want to call the right virtual constructor, you need to cast: TComponentClass(C.ClassType).Create(C.Owner)
    • Streaming
      • AStream.WriteComponentRes(C.Name, C);
      • Create a new instance, then AStream.ReadComponentRes(C); (but if both have the same owner, watch out for Name collisions)
    • RTTI
      • RegisterClass[es] the classes you’re going to use
      • Then you can write a Clone method

Singleton pattern

  • Only one instance of a class
  • Very simple pattern, but very tricky to implement
    • Needs a specific setup mechanism
      • Or can you use a constructor as well?
    • Consider subclasses
      • Data in unit causes some trouble

Adapter pattern

  • Convert the interface of a class into another expected by the user of the class
  • Better than “if X is…”
  • Can be nicely implemented using interfaces
  • Examples:
    • Descend from visual controls, so you can add e.g. “Text” and “Value” properties to  multiple different controls.
    • Interposer class: descendant class that has the same name as the base class. Interesting way to force the runtime to create *your* TButton instead of the standard TButton. Yikes. (Seems like that would be really brittle! The compiler wouldn’t even tell you if you got it wrong.) (It would also be problematic in .NET, if both are in the same namespace.)

Façade pattern

  • Provide a simpler, higher-level interface to a set of interfaces in a subsystem, making it simpler to use and promoting weak coupling
  • In Delphi: a single interface for a collection of components hosted by a container (e.g., providing access to the field values of a dataset on a data module)
  • Shield you from the other guy’s implementation details (at least a little)

Flyweight

  • Replace a series of many objects with a single stateless one, with status information provided on method invocation: pretend you’ve created 10,000 of something
  • The DbCtrlGrid is the perfect example. It looks like it’s got many editors, but in reality it’s only got two

Proxy pattern (Marco writes it as “proxi”)

  • Provide a surrogate (placeholder) for an object (delaying creation cost, if any)
  • Delphi uses something like this for form handles, different reason (that reason being Windows 9x)
  • At design time, a proxy is created for the form you’re editing
  • Proxy components as “light” representations of components (e.g., a database table). Increases total memory usage if you do need to create everything, but decreases time and memory if you don’t.
  • Proxies in OPF frameworks
    • Lightweight objects with few DB columns

Iterator pattern

  • Provide a way to access the elements of an aggregate object sequentially, without exposing its underlying representation
  • Often used with container classes
  • Are iterators better than for loops on VCL lists?
    • Probably
    • The new “for..in” loop is an out-of-the-box implementation of the Iterator pattern

Observer pattern

  • Define a one-to-many dependency between objects, so that when one object changes state, all its dependents are notified of this
  • One of Marco’s favorites, found in the VCL
    • Notification and notification subscription
    • DataSource (a broker that sits between the two ends, and manages the notifications)
    • Actions (I don’t think these are really Observer, since they’re “pull” rather than “push”)
  • Example: a MultiCast event handler
    • Eww, his “MultiClick” is a write-only property. Worse, setting it doesn’t replace the old value of the property – it accumulates. And magically ignores duplicates. None of which is intention-revealing. Very smelly code.
  • A “Real” Observer: demo

Delphi 2006 and Patterns

  • Available with Together support
  • GoF patterns implementations
  • Extensible with your own patterns

Miscellaneous conference catch-up stuff

I guess I haven’t blogged about Tuesday evening’s Meet the Team session yet. Last year, they did a presentation where each of the devs showed off their favorite new feature. They didn’t do that this year, which was kind of a bummer. All they did was have people standing around, near signs with the product names on them, and people could wander up and talk to them. I got involved in, or listened to, a few interesting discussions about everything from comment spam to the number of bugs Danny has fixed (and created). Not bad. They didn’t hand out any betas, though.

This afternoon, I was hoping to go to Chris Bensen’s talk on “C++ and .NET Interoperability”. Unfortunately, that session got canceled. 🙁 We’re not a C++ shop, but we have a large Win32 codebase that we’re looking at moving to .NET, and that move would most likely be done piecemeal, so interop is very much of interest. The description said the session would cover (among other things) mixing the VCL, VCL for .NET, and WinForms frameworks. Man. I was looking forward to that one.

I went to the computer lab this morning and played around with Delphi 2006. I’m liking the new features, especially the edit-completion stuff. I poked around briefly with modifying the existing templates, and was able to fix the template I complained about yesterday. Haven’t tried creating my own template, because it isn’t immediately obvious what all you can do in that XML file, and there’s nothing about it in the Help file yet.

On an amusing note, the IDE seemed quite responsive in the lab, and I found out why when I looked at the System properties… that computer-lab machine had three and a half gigs of RAM! (Please can I have some?)

Empowering Agile Development with CaliberRM

Empowering Agile Development with CaliberRM

Jerry Odenwelder

 

Test-first speaking 🙂 (they had to troubleshoot and test the recording software before the session started)

 

Likes agile – customer involvement, lots of testing

 

  • Individuals and Interaction: People are not pluggable units
  • Customer Collaboration: Customers are ultimate beneficiaries, so need to be involved
  • Working Software: is what adds value to the business
  • Adaptive: Change the process as needed.

Agile Requirements

  • User Stories
    • Can break down into one or many requirements
  • Describes a unit of work that contributes to business value
  • Created by, and owned by, the customer
  • Meets the PET criteria
    • Can be Prioritized
    • Can be Estimated
    • Can be and Tested

Why Use a Tool (instead of index cards)

  • Automation (cut/paste)
  • Disaster recovery
  • Reporting
  • Traceability
  • Distributed Development
  • Scalability
  • Customer is not available

CaliberRM Supporting Agile

  • Light Weight
    • Expert Client
    • Cross-Platform / Web Client
  • Works in your environment (Delphi, etc.)
  • Get the bureaucracy off your back
    • Document generation
    • Reporting
  • Everyone is on the same page
    • Central server

Managing User Stories

  • Rich text editor
  • Attach pictures
    • Take a picture of the napkin and put it in as a requirement
    • No zooming support in the current version
  • Embedded tables (e.g., Fitness)
  • Glossaries: business can write terms they’re familiar with, they’ll automatically be highlighted in the text, and when the programmer hovers over them, they find out what the acronym means
  • Could create a requirement type of “Backlog” and another called “Sprint Backlog”
  • User-defined attributes, e.g., complexity, iteration, requires spike

Collaboration

  • E-mail notifications (customize per group); registered interest
  • Threaded discussions
    • Record hallway discussions
    • If the customer isn’t immediately available, could post questions and get responses back
    • When you log into Caliber, you get a pop-up notification (can disable, can run explicitly later) showing which discussion items you haven’t read yet

Decrease time of meetings

  • Filtering: Remove data from grid that’s not important for this meeting; sort
    • Can save the grid settings and reload them later
  • Edit right there during the meeting

Maintains history of changes

  • Records how requirements change over time
  • Go back and review old version of requirements
  • Document Factory can produce documentation (which even includes the picture of the napkin)
  • History tab: top pane shows history of changes, bottom pane shows what changed in any particular rev
  • No way to require (at the server side) comments for each change

Manage Dependencies

  • Valuable for
    • Impact of change
    • Risk assessment
    • Planning
  • Important Agile Traces
    • Dependent requirements
    • Project tasks
    • Model components
    • Validation procedures
  • Tracing to
    • External files (might be a bad idea in Agile, since the files might change frequently)
      • External revision control system?
    • TestDirector
    • StarTeam
  • View trace matrix
  • When you change one item, the items it feeds into are marked as suspect, so you can go and review them

Baselines

  • Isolate requirements for a release or iteration
  • Once a requirement has been put into a baseline, it can’t be modified through normal editing (you have to explicitly go into Baseline Maintenance)
  • Baselines support digital signatures (if you have compliance issues)
  • Once a baseline is locked (signed), it can’t be unlocked (for compliance reasons)
  • Can diff two baselines, or current baseline with old baseline

Security

  • Supported to User-Defined Attribute level
  • Q: If you’re in an agile environment, do you need security? A: It might not be a bad idea to keep the customer from editing the estimates (grin). Maybe the developer shouldn’t be able to edit descriptions or iteration numbers. And if you’re working with a third-party vendor, you’d want to rein that in as well. The person who drives the meetings should probably have all access.

Conclusion

  • Change is inevitable; embrace it
  • Requirement Capture and Understanding
  • Planning and Risk Analysis
  • Tracking Progress
  • Post Mortems

Q: What happens if you have an unreliable network connection that dies while you’re working? A: Anything they were working on, but hadn’t saved yet, will be lost. The requirement they were editing will be locked until the session times out (or the admin logs off their session).

 

Q: How do you make sure the story gets QA’ed and documented? A: You would probably want to use user-defined attributes for that (possibly in combination with the built-in Status and Priority attributes). Find them by setting filters on the requirements grid.

MSF for Agile Software Development

MSF for Agile Software Development

Granville Miller (aka Randy Miller)

 

MSF is an agile software process that reflects some of the practices used within Microsoft.

 

Agenda

  • Agile Software Development
  • Team Model
    • Team model is the most critical piece of the agile software development process. If you know it, you can answer 90% of the questions.
  • Personas/Scenarios
  • The “Agile” Pattern
  • Shadow Applications
  • Incremental Threat Modeling
  • Context-Driven Testing
  • Risk

Randy usually gives people about a day’s worth of presentation on this stuff, and we’re trying to cover it in an hour, so this will be much abbreviated. There’s much more info available on Microsoft’s Web site (see link, below).

 

Project Success is Rare

  • 2004: 15% failed, 51% challenged, 34% succeeded
  • 2000: 23% failed, 49% challenged, 28% succeeded
  • 1995: 40% failed, 33% challenged, 27% succeeded
  • 1994: 31% failed, 53% challenged, 16% succeeded
  • The good news: State is Improving
    • Small Releases
    • Increased Customer Involvement
    • You’d think success would depend on some new server technology or something, but customer involvement seems more important
  • Agile Manifesto
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
  • An agile method is
    • Iterative
    • Incremental
    • Self-organizing and
    • Emergent.
    • It must include the attributes; otherwise it is a “lightened defined process”.

Activities in MSF

  • There are more roles than just customer and developer. There are architects, testers, etc., who add value.
    • More roles -> communication complexity increases.
  • Composed of 14 basic work streams
    • Basic activity building blocks of MSF
    • A work stream is an activity that is composed of other activities
    • Activities are described using the ETVX format (whatever that is)
    • Contains 70 activities (not including work streams)
    • Most work streams are performed by a single role
  • Roles <-> Constituencies
    • Team of Peers
    • Business analyst: Product management
      • is responsible for two constituency groups: one is the sponsor, the other is the users.
      • is responsible for tracking time.
  • Release manager: in charge of understanding deployment, handing it off. Product manager: responsible for tracking budget and such. They can be combined.
  • Roles
    • Developer
    • Project Manager
    • Business Analyst (handles interaction with customer)
    • Architect
    • Tester
    • Release Manager
  • Work Streams / Goals
    • Capture Product Vision (business analyst)
    • Create a Scenario
    • Create a Quality of Service Requirement
    • Plan an Iteration (project manager)
    • Create Solution Architecture (architect)
    • Implement a Development Task (developer)
    • Build a Product
    • Test a Scenario
    • Test a Quality of Service Requirement
    • Fix a Bug
    • Close a Bug (tester)
    • Release a Product
    • Guide Project (project manager)
    • Guide Iteration (project manager)

Safe Harbor Statement

  • Choose the MSF for Agile Software Development process for projects with results-oriented teams who can work without lots of intermediate documentation
  • “Stretch to Fit” instead of “Shrink to Fit”
    • Minimalist approach
    • Agile methodologies promote adaptation

Scaling to All Project Sizes

  • There’s a matrix for whether it’s a good fit to combine particular roles
    • (P)ossible, (U)nlikely, (N)ot recommended
  • “If you have the skills to play a role, you may play that role”
  • Smallest project size is 3 people (with one or two people, you probably don’t need much process)

Mindsets:

  • More than a set of activities – a collection of values
  • Quality is Defined by Customer
  • Pride of Workmanship
  • Team of Peers
  • Frequent Delivery
  • Willingness to Learn
  • Get Specific Early
  • Qualities of Service
  • Citizenship
  • Different roles. Some care only about time. Some don’t care so much about time, and fight for quality. Who breaks deadlocks?

Adaptation

  • There are many events that may befall a project that are not covered by our process
  • Use best judgment and adapt based on mindsets and principles

Personas

  • Descriptions of a group of typical users
  • Persona represents a “proxy” for the user group, and provides a means to talk and reason about the group through the characteristics of one fictional individual
  • On-site customer is the best you could hope for.
  • Actors in use cases: the other extreme. A developer is a developer.
  • Persona: fictional representations of people.
    • Be respectful.
      • Best Buy did a set of personae for their customers. One was the “Devil Customer”. This was fine until it landed in the Wall Street Journal.
    • Can represent the novice and the advanced developer.
    • Scenarios associated with each persona.
    • Knowledge, skill, usage pattern
  • Can still meet actual customers (and refine our personae).
  • Different people come up with different personae, write them on sticky notes, put them on the board. When you take yours up, you decide whether it should be combined with one of the others, or should be separate.
  • Q: Where do you get pictures to use for your personae? A: Got any artists in your group? Can you buy a CD of stock photography?
  • Baseball cards of personae (including organizations)
  • When you’re trying to make a decision, at least you have a clue.

Jack

  • Role: Online shopper
  • Motivation: Get it quick
  • Usage pattern: Hates shopping but wants to get it quick. …

Incremental approach – Why scenarios over use cases?

  • Risk reduction
    • Changes
    • Delivery
    • Progress
  • Activities need to be able to handle small increments up to a single change
  • A scenario is basically a single path through a use case. Easy to break into smaller increments if needed.

The Agile Pattern

  • Scenario list (aka backlog) -> iteration plan
  • Peel off pieces, add them to a particular iteration
  • The things in the list aren’t actually scenarios – they’re reminders. The business analyst writes them up for the iteration.

Date or Feature Driven

  • Which?
  • Parkinson’s Law: If you give developers more time, they will find ways to fill that time. So you have to be aggressive on the date, right?
  • But not everything is really date-driven
  • “We’re going to deliver in March, even if it’s March 51st”

Minimum Acceptance Level

  • If you ask customers what they want, they’ll list off the Exciters & Delighters. (What do you want in your TV? Remote control, stereo, closed captioning, etc.)
  • But they usually won’t tell you about the Dissatisfiers (must-have requirements) (ability to turn the TV on without the remote, good picture quality, etc.)
  • First few iterations: you work mostly on the dissatisfiers, and a little on the exciters. But you can’t deliver until you make enough progress on the dissatisfiers.
  • So even if time ran out on iteration 3, you still couldn’t ship.
    • Of course, this is all pragmatic. Depends on market. If you really want to be first-to-market, you might ship anyway.
  • Even if you’re date-driven, you might not really be date-driven, because you might not be able to ship without X features.

Feature graphs:

  • Active (until the developer finishes it – doesn’t distinguish ones that haven’t yet been given to the developers to work on)
  • Resolved (goes to test: implemented fully)
  • Closed (tester can run it totally through)
  • Do a stacked area graph over time. Active=red, resolved=yellow, closed=green.
  • If you’ve still got too much red as of the ship date, the project manager and the business analyst have a problem, and need to start talking to each other.
  • If the yellow keeps growing over time, it could mean you don’t have enough testers, or that scheduling is poor (finishing too many items at once), or the test cases are failing (coders are submitting bad code and marking it as resolved, and the testers have to kick it back), or management is putting too much pressure on and the team stops caring about actual quality and becomes totally dysfunctional.

Context-Driven School

  • Value of any practice depends on its context
  • If you absolutely *must* ship by a certain date or the company runs out of money, you might be incented to ship something that’s not ready. Is that the right thing to do? It depends on how the market reacts.
  • There are good practices in context, but there are no best practices
  • People, working together, are the most important part of any project’s context.

Context Driven Approach

  • Testing that is acceptable on opne project may be criminal on another
  • Define shipping criteria based on what’s important to us
  • Release criteria
    • No Severity 1s and 2s in the shipping product
  • Testing thresholds
    • Code Coverage for Unit Test
    • Getting 60% code coverage is really normal
    • To get 80%, you start using things like mock objects, and it gets harder
    • To get 95%-100%, you start building scaffolding and bizarre stuff
    • What’s right? Answer: it depends entirely on the project.
  • Focusing on statement and branch coverage is not sufficient.
    • Missing code
    • Incorrect handling of boundary conditions
    • Timing problems
    • Memory leaks

Bug debt

  • If the developer has more than 30 bugs, it’s time to schedule a bugfix iteration, where you fix bugs (and fix bugs only)
  • Worth doing even though you take a hit on velocity, because you’ll take a hit on velocity anyway (because you either fix them as you go, or they slow down your coding or testing)

Conduct Exploratory Testing (One Heuristic)

  • Assume a persona
  • Time-box
  • Traverse the system looking for new goals, roadblocks, or improvements, keeping the needs of the persona in mind
  • Add any new bugs, scenarios, or quality of service requirements discovered using this process

Risk and Agile Processes

  • Agile processes drive out risk through short release cycles and customer feedback.
    • Requirements risk
    • Implementation risk
    • Quality risk

Governance

  • Objectives Reviewed
  • Progress Assessed
  • Test Thresholds Evaluated
  • Risks Identified and Mitigated
  • Deployment Ready

Methods of Adoption

  • Organization / Team
  • Grassroots – individuals find the practices useful and the process spreads by providing value
  • MSF provides friction-free usage that doesn’t get in the way

More info

  • http://www.microsoft.com/msf – download “MSF for Agile Software Development (Process Guidance Only)”; has much more info than this presentation
  • Will be released in book form – MS wants to ship it with Team Foundation 1Q next year

Agile Methods with Borland

Birds of a Feather: Agile Methods with Borland

Matt Gelbwaks – Borland

 

This was pretty much exclusively done as a Q&A session. We came up with questions up front, and then they tried to answer as many as they could.

 

Note: All the questions we ask during this session are going to become requirements and scenarios in Borland’s feature backlog. Cool!

 

Interesting idea: show a scatter graph of estimated vs. actual time for each story. Hopefully that scatter graph will get closer and closer to a 45-degree line over time.

 

If we have ideas for new information radiators we’d like to see, tell Borland, or e-mail an example to Dan Massey. That’s dmassey, on the obvious domain name.

 

What’s Borland’s experience with agile?

  • Borland was doing agile before there was agile: in 1992, they were already doing short iterations, etc.
  • Today, some teams are doing formal Scrum with StarTeam
  • Larger projects: “release train” (like Eclipse – I’m not sure exactly what that means…)
    • 6-week milestones
    • Some teams do smaller iterations within that
    • All requirements in CaliberRM
    • All bugs in StarTeam
    • Starting to use Tempo
  • Many of Borland’s larger clients have SarbOx requirements, and have audit requirements. Need to prove that the work is being done the way it’s supposed to be done (so some developers need to spend their time auditing instead of developing). To really do agile, they probably need to automate that.

How do we capture key design decisions in Together?

  • e.g., how do you capture the alternatives that were considered?
    • Consider: Instead of making a decision, hold off as long as possible, to show you’re thinking about it. Include all three options in the diagram, label them somehow. As you figure out what will drive the decision, you can keep notes. (last responsible moment)
    • Keep track of the set of options that are available. Don’t collapse them into an actual decision until the iteration where you depend on that decision.
  • There are some feature requests that might cover this…
  • Short-term: using a Description field to record those decisions; whenever a decision is made, it should have been a requirement, so roll that back into the requirements repository (so it may feed into other projects)
  • Could use version control to store the history of the discussion (StarTeam’s threaded discussions).
  • Use linkages between tools (e.g., links into CaliberRM)

How do you reconcile informality of agile with formal communication?

  • Agile does require discipline, and a way to be measured.
  • Use the discussion feature in CaliberRM to record the hallway discussion you just had (and why).
  • You can’t necessarily capture those hallway conversations. But when you’re having an actual meeting, bring up the requirements grid and change it right there – don’t make notes and update the requirements later.
  • Give visibility to the time you spend on formal communication.
  • Problem with discussion feature: no way to find out whether there are open questions still hanging. Is the thread closed?

Selling agile to management

  • What’s the problem you’re trying to solve? Measure it and start improving: timeboxes, testing, etc.

What do you do when you can’t find someone with the time to play the role of customer?

  • Borland’s actual clients don’t have a body to send to Borland, so Borland uses full-time surrogates
  • If you can’t even get a full-time surrogate, try doing a big investment of time up-front, using Maya or some such
  • Then use tools like CaliberRM to keep the discussion going in trickle format
  • Three axes to address – people, process, technology
  • People
    • Deliver early and often
  • Process
    • More time up front
  • Technology
    • Radiators
    • Web context
  • Possiblity #1: If there is no customer who thinks it’s worth their time, there’s no agility – and the value of the project is zero. If management isn’t willing to make a person available to tell you whether you’re on the right track, there’s zero chance we’ll deliver what you need, and this whole project is wasted effort.
    • Maybe the person you’re delivering to isn’t really your customer. They might be your end user, but they’re not your customer.
    • Go ahead and deliver the wrong thing (which it will be, since nobody ever told you what they wanted), but deliver it with panache. If you get them mad at you, maybe they’ll take a little more interest. (Nice idea if this actually worked…)
  • Possibility #2: Sit down with customer and Maya, to elicit requirements. Deliver something tangible and viewable, quickly, that shows understanding. (Maya is coming out sometime next quarter) Or otherwise find a way to show value immediately.