[8:25] I’m sitting in a conference room in Bellevue at the Net Objectives corporate office, waiting for Day 2 of an Agile symposium – “Team and Technical Agility” to begin.  Registration began at 8:30, which involved checking your name off of a list and filling out a name tag.

[8:32] I got WiFi access!  there are helpful instructions on the wall next to me.

[8:37] Other teammates start showing up.  Mary, Michelle, and Sumair are all here; rumor has it that Nate will show up.

[8:44] Reviewing the brochure-ware.  Everything says “Lean-Agile,” instead of just “Agile”, which tells me (a) how far the term “Lean” has come, and (b) how relatively deprecated the term “Agile” is as a standalone term.

[8:47] Glad I brought healthy food on the advice of a coworker who attended Day 1 of the symposium yesterday.  These doughnuts do not look like toga-enhancing foodstuffs.  I brought a banana and a fruit and cheese plate from Starbucks, which should last me.

[8:55] Random phone call from home  Gah.  People are still filing in and getting acquainted.

[9:00] Getting started.  The presenter, Net Objectives CEO Alan Shalloway, tells us that there will be a little overlap with previous sessions.  Several people are here for the 2nd or 3rd day in a row.

[9:02] Alan tells us that the course materials will be up on the web in a day or two.  I’ll link to them when they’re available.

[9:03] Alan has written a lot of books.

[9:04] Whiteboard cleaner smell is making me woozy.  I’m seeing double.  Where am I again?

[9:06] Referring to my previous comment about the use of the term “lean” vs. Agile, on Alan’s bio page, Lean is mentioned five times, Kanban once, Agile twice, and Scrum twice (includes names of books).

[9:08] Four pieces to Agile: Business driven agility.  Annual vs. quarterly planning cycles (this has a dramatic impact).  Agile teams.   Big gap between business-driven agility and agile teams.  Management is necessary to bridge the gap.

[9:09] Gossip: Alan doesn’t like the “chickens and pigs” agile metaphor.  Implication is that chickens aren’t as much a part of the team as pigs, when really it takes everyone’s contribution.

[9:10] Definition: Enterprise-level is 100+ people.  When you’ve got 10 people, just use Scrum, it’s no big deal.  For larger organizations, scaling from the bottom doesn’t work as well.  We’ll talk about managing business processes – managing resources, dealing with product portfolio management, and then, on the team side, we’ll talk about processes and technical considerations.

[9:14] First part of the day will be about “Self-Organization and Achieving Team Flow”.

[9:16] “Software is more of a discovery process” – parallels the work of designing a product prior to manufacturing.  Interesting.

[9:17] Alan is whiteboarding the “Business Operational Value Stream”.  Software development parallels, and supports, the BOVS.  Start with the BOVS and then see what you need from the software, rather than vice-versa.

[9:19] The act of “building” software is only a part of the software development process.  Most of the time is spent in (a) discovering what the customer wants, and (b) discovering how to build it.

[9:21] “How people talk about things has a huge impact on how they do things.”  True.  Shades of a previous blog post I wrote about manifesting your own reality.

[9:22] Thinking of the development team as a pipeline.  How do we decide what goes in?  What’s the ideal size of items in the pipeline?  Feedback loop – from the end of the pipeline (finished work) back to the beginning (decision-making time) – is essential.

[9:23] Alan suggests that the phenomenon where management adds too much work onto team queues is mainly due to lack of visibility.  That’s part of the reason I love our current iteration planning and project board process.

[9:26] There’s power in not only knowing WHAT you’re doing, but also UNDERSTANDING what you’re doing.  They’re different.

[9:27] New slide that presents Agile as a subset of practices within the larger “Concept to Consumption” Lean cycle.  Patterns/TDD is a further subset of Agile proper.  Talk about Lean with requisite history of Toyota, Deming, etc. etc.  Alan talks about the “just-in-time” concept.  Don’t analyze until you’re ready to code, don’t code until you’re ready to test.

[9:30] Paradigm of Lean: Focus on sustainable speed.  Lean Focuses on the ability to add value quickly now, while improving the ability to add value quickly in the future. This is excellent.  I like the bipolar emphasis: now and future both are important.

[9:32] Teams must define their own workflows (not management).  Attend to work-in-progress, and attend to just-in-time.

[9:33] Age-old question: what is software development like?  Is it art? (Alan thinks no, even though there is an element of creativity).  Is it craft? (Maybe).  There are rules to how software development works.

[9:37] We talk about value.  Value = “What the customer wants.”  What they’re willing to pay for, or what endears you to them.  Information that is used to create value can be valuable on its own.  The Lean Value Stream: the flow from beginning to end of creating the value.

[9:40] Good slides that distinguish between calendar time, to time actually spent working, to delays between phases, to loopback/mistakes/delays.  Definition of Process Cycle Efficiency = Time Worked / Total Cycle Time.  Big question: how do we take less time to do the same work?

[9:42] What’s the causal effect between cost and quality?  What about between cost and time-to-market?  What about the causal effect between higher quality and cost?  Lean says: focus on time and quality and this will cause costs to go down.

[9:46] Lean doesn’t focus on pure productivity (i.e. lines of code per day), but rather, how much time does it take to get something done – looking at from beginning to end.

[9:48] A lot of people spend too much time managing queues when we’ll never have the capacity to get to all the items anyway. *cough*

[9:49] Time is important.  Focusing on delays uncovers problems.  Ultimately, we want to optimize the whole.

[9:52] Root-cause analysis: Ask “why” at least four, maybe as many as six, times, to get to the root of the problem.

[9:54] Metrics can cause problems – the problem may actually be in another area.  Improvement may be removing problems the team has to deal with, but which they haven’t caused and don’t have the ability to fix.

[9:55] Common impediments: Delays, Thrashing (context switching), Overloading (too much work in progress)

[9:57] Overview of Scrum.  I could give this part of the presentation myself.  So could probably half the room.

[9:59] Overview of Kanban. “It’s a horrible name.” ROFL.  He presents it as similar to Scrum, but working on only one thing at a time.  Keep the queue small.  No iterations, no timeboxing.  Takes a bit more organizational maturity than Scrum.  Gives teams a lot of flexibility.  Lets you focus on bottlenecks.

[10:01] Overview of Scrumban.  Like Scrum, but explicitly limit Work-in-Process.  This is doing Scrum within the context of Lean thinking.  Re: Scrumban, go check out Corey Ladas’ (good) stuff.

[10:03] Alan tells an anecdote about a trip to Tokyo.  I’m reminded, for no reason in particular, of the movie Kill Bill Vol. 2.

[10:05] Common Anti-Patterns: Stories not completed in an iteration.  Stories are too big.  Stories are not prioritized.  Teams work on too many things at once.  Acceptance tests not written before coding.  QA/Testing is too far behind developers.  All are familiar to me.

[10:08] Other challenges: Too many escalations (bugs, hotfix requests).  Also, specialization of people makes resource management difficult.  We run into this when dev is complete, but QA still has a lot of work to do.

[10:09] I’ve eaten three bananas today: one pre-workout, one post-workout, and one for breakfast when I got to the seminar.  I am not a monkey.

[10:10] Talking about Kanban in a little more depth.  Kanban principles: Improve lead time.  Limit Work-in-Process.  Pull management.  Use visual controls.  Build quality in.  You can start with Kanban now – just put limits on WIP or queues, and create transparency into WIP.

[10:13] Interesting divergence into notions of transparency of WIP.  Some advocate that the iteration should be a black box, because it’s a non-deterministic process.  Others like transparency.  “The alternative to transparency is a threat” – we’ll abort the sprint if you force my hand.  This is a CLM (career-limiting move).  Overall I get the impression that Alan is definitely in favor of transparency.  He says that this is one of the big differences between Scrum and Scrumban.

[10:16] Just-In-Time: Don’t write requirements before they can be used.  Don’t write code before it can be tested.  Don’t test more code than can be deployed.  Don’t release features that nobody needs right now.

[10:17] Q: “How does your process help you achieve your common sense?”

[10:18] Just realized I have a lot of pride in being the first to implement physical project boards at Parametric.  Does pride goeth before the fall?

[10:19] Target of Kanban: Smooth flow.  Achieved by limiting WIP.

[10:20] Alan’s opinion is that the best book on Kanban right now is the set of Corey Ladas’ essays, available for $10 as an e-book on lulu.com.

[10:22] Anecdote about the emergency “silver card" for use in Kanban.  Is this sort of like Willy Wonka’s Golden Tickets?

[10:23] Discussion about service-level agreements between product managers and the team.  This presupposes transparency.  Silver cards, red cards – it all seems invasive to me.   Am I a black-box radical?  Maybe somewhere in between.  Alan could use a slide animation that shows the silver card / red card usage and flow.

[10:27] Cumulative Flow Diagrams: We do this, but reversed.  We see blockages and air bubbles (Ladas’ term).

[10:28] Table comparing management visibility of Scrum, Kanban, and Scrumban.  Alan compares “business-driven” Scrumban/Kanban vs. “team-driven” Scrum.

[10:31] CPI (continuous process improvement) happens way faster in Kanban than Scrum, according to results presented at Miami Lean/Kanban conference in May.  Why?  Focus on process, not people (less fear).  Gave ability to test theories (true PDSA).  Enabled people to think in concrete terms and infer principles from what was happening.  I LOVE THIS.  I love thinking tangibly (concretely) about software issues.  Some of my biggest hair-pulling moments come when I’m talking to somebody about producing software – as in deploying working code to the customer – and they want to talk theory.

[10:33] There’s a virtuous circle between intuition and being able to explain something.  The better one gets, the better the other gets.  This is one of the offshoots of blogging about tech: if I can describe it to someone else (you, dear reader!), I’ll get better at doing it myself.

[10:35] “How long does it take an agile team to gel?” – Alan says as many iterations as there are team members.  That would imply 6 iterations, or  12 weeks, for our team.  I think that number should be doubled, or perhaps our team learning is half as effective as it should be.

[10:36] I think my bladder can hold out four minutes until the scheduled break.  I think.

[10:39] First mention of Goldratt’s Theory of Constraints, from a question from the audience.

[10:44] Big Picture: Picking the right process may not be as important as where to start.  Agile is not just about teams.  Business agility + Team agility (with proper management) = Enterprise agility.

[10:49] We’re not doing Scrum at this seminar because the presentation sessions aren’t timeboxed.  As in, break was supposed to start 9 minutes ago.  This notice brought to you courtesy of my coffee-fueled bladder.

[11:02] The Parametric team:

[11:03] Break is almost over.  I resisted the doughnuts, even though I’m starving.  With these morning workouts, my metabolism runs as hot as a superbike.

[11:09] And, we’re back.  Next session: “Removing impediments while facilitating feedback.”

[11:10] Talking about getting requirements using the example of designing a car.  This is great for laughs, but in reality, the analyst, the product manager, and the developers already share enough context to get past the humorous pratfall-scenarios where the product manager says “I want a car” and the development team delivers a Hot Wheels toy.  Misunderstandings are most often present at a deeper, almost subconscious level.  It’s the trick of a good BA to make those assumptions that lead to misunderstandings explicit, communicate them, tease out the implications, and wash, rinse, repeat.

[11:17] Talking about speed and reordering development steps.  Consider putting “specify test” and “write test” before “design” and “code”.  Note: specifying the test and writing the test and running the test are all very different things.

[11:21] Important question to consider (early): “How will I know if this thing we’re developing actually works?”  I love this question.  Perhaps second only to “How will we know when we’re done?”  The imprecation, of course, is to specify and write your tests early.  We try to do that, but we could always do this better.

[11:25] This part of the symposium is off to a slow start.  I’m missing the map, the high-level purpose, the goal of the section.  There’s a good lesson for trainers: you can probably never spend too much time re-orienting your audience.  Keep them aware of the map.

[11:27] Alan shows the Dilbert cartoon where the pointy-haired boss offers $10 for every bug the developers find and fix.  Dilbert and Wally go crazy with glee.

[11:28] “Vicious cycles” – customer wants new features yesterday.  Result: sloppy, complex code with lots of bugs, and an exponential increase in time to add new features. I like that italicized part – it’s so true.  You add crap to the pile linearly, but the volume of crap increases exponentially.

[11:29] Another vicious cycle, focused on testing and lack of quick feedback between QA and development.  The worse it gets, the worse it’s going to get.

[11:30] Moral: don’t optimize via decomposition.  Optimize the whole.

[11:31] “Span of control” – the idea that you hold people accountable for what they can control = Not Useful.  Useful = “span of influence.”  Measure this at the team level.  He mentions a book by Joe Caruso called The Power of Losing Control.  Reminds me of a book I read about finding strength when forced to wait.  Can’t remember the name.

[11:33] Difference between perceived integrity (customer expectations) vs. conceptual integrity (developer expectations).  Does your system have both?  Thus, there are two kinds of inspection, via Poppendieck: inspection to find defects (wasteful), and inspection to PREVENT defects (useful).

[11:35] The role of QA: PREVENTING defects, not FINDING defects.  Useful way to think.

[11:37] Alan is talking about the traditional developer tension with QA.

(personal note) It occurs to me that our team has less friction in this regard than maybe any team I’ve ever worked on.  Why is this?  Start with good people, for one; foster a team focus; don’t establish a culture of blame; ensure that your dev manager (that’s me) enjoys and values QA as much as writing code.

[11:39] Deming quote: “Let’s make toast the American way – you burn, I’ll scrape.”  Funny.

[11:41] Talking about FIT tests. Good question in an otherwise snoozy topic: “How do you know if you’ve asked the questions you need to ask?”  Good question for business analysts to ask themselves.  Leads into a discussion of acceptance criteria.  “How will I know if I’ve done X?”

[11:46] FIT test drama – a requirement was misunderstood?  In other news, the earth revolves around its axis, bears shit in the woods, and the Pope wears a funny hat.  I get bored with these examples, because they WILL NEVER GO AWAY – the trick is, how do we (as a team) recover from these misinterpretations / missed expectations / misunderstandings?  Alan gets to the point – improve the conversation between the project team members.

[11:50] I’m ambivalent about this FIT test lesson: another alternative to specifying all the itty-bitty details about what is considered overtime/holiday/Sunday pay is, let the product owner spit out the original (sloppy) requirement, let the developers code it, then let the product owner do a Phase II requirement when they realize that they missed some essential definitions.  Would that take less time?  Would it mean less of an impulse to overspecify the requirements?

[11:54] “Don’t let something get into your sprint until you know how it’s going to get OUT of your sprint.”  – Dean Leffingwell.  Moral: know what your acceptance criteria are.

[11:56] I love the term “Product Champion” – I’m always reminded of Kirk Douglas as Spartacus, for some reason.  “I AM SPARTACUS!”

[11:57] Alan likes automated tests.  At the very least, specify your tests ahead of time.

[12:06] Team discussion time.  Mary and I trade war stories about our favorite product owners.  My conclusion: it’s better to be able to adapt quickly than to try to get perfect requirements.  Change happens – plan for it.

[12:09] Alan proposes “Acceptance Test Driven Development” as a counterpart to “Test Driven Development”.  This statement sort of summarizes the gist of the last hour of slides.  Write tests early; get talking to the customer early; know what the definition of done is; automate your testing process as much as possible.

[12:11] Starving.  I want to say it like Zsa-Zsa Gabor.  “Stahving, dahling!”  Lunch is in 30 minutes.

[12:14] Alan talks about “units”.  The juvenile frat guy inside of me avoids smirking.  Barely.

[12:15] (personal note) Is FIT good only for easily-quantified algorithms?  I worry about FIT as a crutch that ends up hiding higher-level tests that we should be talking about.  As if predicting my unease, Alan puts up a slide that says “Acceptance tests and tables are not a substitute for interactive communication.”

[12:17] A shout-out to Uncle Bob.  “Difficult to test business logic via the UI.”

[12:20] Alan brings up a Celsius-to-Fahrenheit conversion problem.  I’m reminded, painfully, of all the decimal precision problems we’ve had in a couple projects at work over the last six months.

[12:23] Amir is up with an example; I’m not sure for what purpose he’s presenting the example.  Again: you can’t re-orient the audience often enough.  He presents a nine-dimensional car sales problem.

[12:30] Exponents!  Get yer exponents here!  We’re “mathy!”

[12:32] Amir has it wrong: the concept of the “selection of cars” is really an implication of the algorithm used to determine the selection.  There’s a whole field in mathematics that tries to prove algorithms independent of the data used as inputs into the algorithm.  How do you prove a system is Turing-complete?  Not by analyzing inputs and outputs.

[12:37] Again, he has it wrong: it’s impossible to test a single criteria in isolation: this is an algorithm with nine inputs, and “testing a single criteria” is really “testing one criteria, HOLDING THE OTHER EIGHT CONSTANT.”  That caps-lock assumption is still part of the test.  I don’t know, maybe that’s what he really means, but I tire of these semantic games: “agree with me on my set of definitions and I’ll give you the answer that I want to give.”

[12:43] I fear we’re about to go off into a discursive analysis of Plato’s Theory of Forms. “There’s no such thing as an example – just an example of <x>”.

[12:45] Lunch is overdue by five minutes.  Shaggy and Scooby would be SO out in the hallway right now, digging into the buffet.  I’m taking one for the team and holding candles to the wall. (ref: previous note)

[12:47] I just found out that there are evaluation forms.  Also: 30% off book sales.  Subtle promo for Scott Bain’s Emergent Design, which looks like a great book.

[12:50] Lunchtime!

[1:21] Yummy Thai lunch – better than your average buffet.  We sat outside in the nice weather and had a good discussion about work.

[1:32] People are starting to straggle back in.  Next session is “Avoiding Under and Over Design in Agile Projects.”  BDUF (Big Design Up Front) vs. NDUF (No Design Up Front).  Or, how to find the sweet spot in the middle.

[1:39] Discussion of acceptance tests vs. unit tests.  What are each good for?  Lots of good discussion.

[1:41] When refactoring software, need to take into consideration the safety factor.  Is it safe to change our code?  Safety is independent of brittleness/ease of change.  Acceptance tests play an important role in ensuring safety.

[1:45] Starting to talk about Emergent Design.  “Test” can be thought of as a verb or a noun.  In our context, we’re using test as a noun.  The specification for what we’re going to deliver. 

[1:51] Qualities and Pathologies slide: Strong Cohesion, Proper Coupling, No Redundancy, Readability, Encapsulation.  Each has goals and pathologies.

[1:56] More details on encapsulation.  Diving deep into the details.

[2:00] Unit Testing.  This is stuff we already know.

[2:01] Refactoring: More than just “improving the design of existing code.”  Shout-out to Martin Fowler’s classic book Refactoring.  Three kinds of refactoring: start with a mess, then go back and fix later.  Second: write fast, then immediately refactor.  That’s a style, and it’s OK.  Third: perfect code, but requirements change.  Then you have an insufficient design.   Definition of code debt: you learn something new, but you don’t put what you learn into your code.

[2:04] Moving on to a case study.  Looking at some UML documentations.  Ahhhhhh!  Hopefully this section will move along quickly.

[2:12] “Inheritance to reuse code is (possibly) not a good idea.”  Understatement!  We have one or two projects at work that suffer badly from this problem.

[2:14] Talking about Design Patterns, the Gang of Four book.  It established a new way to design object-oriented code, but it takes a long time to understand.

[2:15] GoF Guidelines: (a) Design to Interfaces  (b) Favor object aggregation over class inheritance (c) Encapsulate the concept that varies.  Detailed slides on each of these concepts.  Good review, but mostly review for me.

[2:23] Slide on “What are Design Patterns?”  Interesting point: Patterns have led to new modeling techniques.  Shout-out to the Head First Design Patterns book.

[2:25] Alan says that Bob Martin said “Don’t build frameworks (up front)” at an SD West conference years ago.  I wholeheartedly agree.

[2:33] Still on the “chip” case study.  Walking through test-first approach, diagram of the solution, etc.

[2:36] Talk about the Open-Closed Principle.  Software should be open for extension, but closed for modification. (Bertrand Meyer).  i.e. you shouldn’t change what you have, but you can extend what you have.

[2:46] Use names to reveal your intentions.   As your intentions change, change method names, class names, etc. that better reveal your new intentions.

[2:48] Q: What were you doing when you (inadvertently) put a defect into your code?  This is a useful question to ask in terms of learning how not to repeat your mistakes.

[2:50] It’s not a coincidence or just good luck that we can easily make changes to existing code.

[2:52] The XP concept of “do the simplest thing that could possibly work” is a hard argument to have (or win), precisely because you don’t know in advance what’s going to change.  Maybe nothing will change!  Maybe everything will change!  (personal note) The principle is that you use your experience, judgment, and common software engineering techniques like encapsulation, etc. to give you room to move at very little cost.

[2:55] When we have certainty, do Pattern Oriented Design.  When we have a lack of certainty, use TDD, supported by refactoring and take small steps.

[2:56] Keep technical dependencies low.  Alan shows slides about ways to minimize dependencies.  Some talk about the Value-Object pattern.  Another UML slide, but this one is animated.  Fun!

[3:04] When you can decouple, decouple!  But don’t build big frameworks up front.

[3:07] Mocks on a Large Scale.  I’m immediately perky.  I love mocks.   Shout-out to Michael Feather’s book on working with legacy code.  Good quote from Winston Churchill: “This document, by its very size, protects it from ever being read.”  Alan seems to prefer that the mocked-component team build and provide the mock component, rather than the team that needs the mock.  It minimizes risk.

[3:11] Important note: if there are changes down the line, the mocks change and the tests change.

[3:12] Break!

[3:28] Next segment: “Design Patterns Explained”.  Considering he wrote a book on the topic, I’m expecting great things.

[3:34] T-shirt demonstration.  Are they for sale? Are they going to be seminar swag?  One doesn’t know…

[3:37] Alan demonstrates the “magic deck of consulting cards.”  Apparently this is sort of like the Magic 8-Ball; you ask questions of the deck, and you pull  out the correct answer.

[3:40] “How would you design something if you knew up front that whatever your design was, it would be wrong?”  Interesting question to ponder.  Answer: do something as cheaply as possible.

[3:44] Slide on “Commonality-Variability Analysis” (CVA).  Shout-out to James Coplien, who wrote a thesis that abstract thinkers will like very much.  I think I’ll avoid it – I’m a concrete thinker, as I mentioned earlier.

[3:48] Avoid the temptation to think of abstraction solely in terms of data abstraction.  There is also behavior abstraction.

[3:49] “From an architectural perspective, commonality analysis gives the architecture its longevity; variability analysis drives its fitness for use” – from Coplien.  From Alan: you get the concepts from the variations: example: red and blue are variations; the basic concept is color.

[3:51] Exercise on Commonality-Variability Analysis.  Teaming with Mary again, yay!

[4:01] We talked about taxes.  It was more interesting than perhaps it sounds.  We’re going through the discussion right now.  I see the importance of separating, or teasing apart, concepts that we normally put together without thinking.  Decoupling concepts.  Making few assumptions about context. One idea is “what are the rules?” and a separate concept is “when do these rules apply?”  Example: German maximum shipping weight of 40kg.  The rule is “You can’t ship more than 40kg,” but you APPLY the rule only when dealing with German ship-to addresses.

[4:08] You try to find commonalities and variations that are actually useful.  This takes experience and judgment.

[4:13] Discussion of “the Analysis Matrix”.  You do want to get to the very specific cases, but you also want to see how the very specific cases fit under some umbrella/general concepts.  And it’s an unfolding/evolving process.  First technique: split out cases and try to “bind” variations together.  In the analysis matrix, each column is a case, and each row is a concept for which the case has an implementation.  Under two conditions: customer is complete and consistent – you’ll get a completely-filled-in analysis matrix.  Never happens, but it COULD happen.

[4:20] It’s 4:20.  That is all.

[4:21] The analysis matrix can be used to help tease out unknowns that the customer hasn’t mentioned/doesn’t know.  Asking “is there anything else you haven’t mentioned?” doesn’t always work that well.

[4:27] Talk about object instantiation, factories, the Abstract Factory method from GoF.

[4:30] About to sign out.  The seminar is concluding shortly.  I hope that if you’ve read this far, you’ve enjoyed the recap – I’ve certainly enjoyed this liveblogging experience and really feel like I got a lot more out of the seminar than if I was listening passively.  Concluding thoughts:  (a) Alan is a great presenter (b) this seminar was excellent, especially considering the price (free!) (c) I enjoyed attending the seminar with friends from work.