Agile 2011 Day 2 Review

Agile 2011Day 2 at Agile 2011 in Salt Lake City kicked off with Todd Little advising that the conference this year had 1604 attendees from 43 countries and from 968 submissions we ended up with 268 sessions. Here are my notes.

Keynote – Why Care About Positive Emotions

Barbara Frederickson led with a keynote, but unfortunately I didn’t get to stick around for much of it as I needed to prepare for my session following. Two brief notes I picked up were:

  • positive psychology is about resilience, the closest concept in psychology to agile
  • positive emotions open us – we are more creative and can see more in the periphery, we have more resilience to bounce back, better performance on exams
From Agile 2011

The Speed To Cool: Agile Testing And Building Quality In

The session that I presented with Adrian Smith from Ennova was close to a full audience and was also one of a handful of sessions that was chosen to be recorded. We received lots of great feedback. The slides are available in a separate post. The following pictures were Adrian and I outside the room prior to the session:

From Agile 2011
From Agile 2011

Agile Coaching Self-Assessment – Where Do You Stand on the Competencies?

This session was limited to 32 participants, so it was with good luck and planning that I was able to sit in workshop facilitated by Lyssa Adkins and Michael Spayd.

Coaches are energy shifters and are tuned into the atmosphere of the room. We were invited to walk around the circle and reflect on the following areas:

  • agile-lean practitioner – people who know the tools and practices
  • business mastery – know what the business needs
  • coaching -professional coaching
  • mentoring – help people access what they already know
  • technical mastery – help people create great software
  • transformation mastery – help people change
  • teaching – teach people what we know
  • facilitating – neutral assistance to a group
From Agile 2011

We were then invited to walk around the circle and land at:

  • the area of strength where I am drawn to
  • area of nervousness
  • area that would make the most difference in your role

and we discussed and shared out thoughts with others standing in the same quadrant as well as the rest of the group.

We then reflected on where we stand right now and where we want to stand, before pairing up with another participant for a short one on one session.

Finally we reflected that the coaching stance and catalyst leader are the heart of the wheel.

This was an awesome session and something I look forward to running with some of my colleagues as well as reflecting on my strengths myself.

Refactor Your Wetware

Andy Hunt (of Pragmatic Programmer fame as well as Agile Manifesto signatory) delivered this session based on his latest book Pragmatic Thinking and Learning: Refactor Your Wetware. Here are my notes from the session:

From Agile 2011

Software is written in our heads, that is where the problem starts!

Context patterns neuroplasticity:

  • context – need to not look at a whole object but how it fits into the whole system
  • patterns – in pair programming, the navigator can see patterns because they are not concerned with the symbols and syntax, pattern matching is the key to expertise
  • neuroplasticity – humans can grow new neurons, but not sitting in a cage or a cubicle, work with enlightened people or in a sensory rich environment you will grow new neurons, but if you don’t use parts of your brain it will get rewired

If you study in an artificial environment you will get artificial results.

Skills – the Dreyfus model – rules –> intuition, consider everything –> relevant focus –> detached observer –> part of system

  • novice – no experience, accomplish a goal, want to get it done, don’t know how respond to mistakes, only way to be effective is to have contact-free rules (ie working in a call centre, following a script), need recipes to follow, can’t get much productivity from this level
  • advanced beginner – start trying tasks on your own, don’t want the big picture
  • competent – build conceptual models, troubleshoot on your own
  • proficient – want to understand the big picture, want to understand why, frustrated by oversimplified information, self correct previous poor task performance (retrospectives are a good example of why they need an experienced coach), learn from previous experience, can understand and apply maxims
  • expert – primary source in their field, continually look for better methods, work from intuition, world does not really work on rules it works on experience
  • second order of incompetence – know what you don’t know and admit to it
  • nursing practice shares a lot of similarity to software development – you need to solve problems then and there – need to become outcomes-based, importance of the individual, keep experts in practice, pay based on value added to the company
  • South American monkey trap is like the tool trap – confuse model with reality, de-value traits that cannot be formalised, legislating behaviour that kills autonomy, alienated experienced practitioners, demand for conformity of tools, insensitivity to contextual nuances
  • brain is not a computer – made up of L mode and R mode and we switch between them – spinning girl exercise – creativity and intuition works better in R mode
  • image streaming – pose a problem to yourself, close your eyes for 10 minutes and then for each image that crosses your mind describe it out loud, image it with all five senses and describe it in the present tense
  • free form journalling – first thing in the morning, write three pages long hand, uncensored, don’t skip a day – way to get it out
  • Thomas Edison used to take a nap with a cup of ball bearings and when it dropped he would wake up and write down what he was thinking about
  • whack on the head – look at problems from a different point of view or the opposite – a good tool is the Creative Whack Pack iPhone app
  • ten mental locks – the right answer, that’s not logical, follow the rules, be practical, avoid ambiguity, ……
  • you need to keep track of your ideas, otherwise you will stop having them – everyone has great ideas, fewer keep track of them, even fewer act on them and very few can pull them off
  • carry something with you all the time to record notes – tools like The Pocket Mod or Evernote
  • mind maps
  • we miss things that change slowly – this happens on projects on all the time
  • 90 cognitive biases that people suffer – memory stinks – every read is a write that can create false memories, anchoring, fundamental attribution error, need for closure (agile estimation) – we will take any information even crap information for closure – in agile we want to keep things open ended, exposure effect, Hawthorne effect, relativity
  • ask yourself how you know what you know
  • your age group changes the way we view and understand things
  • some people need auditory, visual, kinetic
  • how to read – SQ3R – survey, question, read, recall, review
  • how to take notes – make a mind map, the sensory of pen and paper is better
  • use a wiki – has a category
  • use affinity mapping with post it notes – Behind Closed Doors describes this in more detail
  • get your ideas out there and blog it, tweet it, present it
  • multitasking – when you get interrupted your memory is blown, constantly checking email is an IQ drop of 10 points, three times as much as smoking a joint!
  • send less email and you will receive less email – pick up phone, walk down the hall
  • choose your tempo for an email conversation
  • don’t context switch – scan queue once, put things into piles, no mental lists (GTD)
  • set cues for task resumption when you get interrupted, leave a quick mote in code or on a notebook – gets back to resuming task much faster
  • set team interruption protocols – most teams say this is the happiest times they have coding
  • second monitor is a 20-30% productivity gains – ALT-TAB in windows is context switchin
Change is hard:
  • start with a plan
  • avoid inaction not errors
  • new habits take time (3-4 weeks)
  • belief is physical
  • take small next steps

This was a great session with so many techniques to look (and re-look at). As a result I think I will also add this book to my reading list (especially given that The Pragmatic Programmer in one of may favourite books). Finally, Andy reminded everybody that the Pragmatic Programmers also have a free magazine that is worth checking out.

After Dark

Tuesday night is typically the night that most of the vendor parties happen. I managed two invites – one to the Atlassian Drink-Up (which unfortunately due to talk preparation I ended up missing) and one to the Celebrate with Rally party which I was able to make for a couple of hours at the end.


Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 2 of the conference.

Agile Australia 2011 Day 2 Review

Agile Australia 2011Day 2 at Agile Australia 2011 and another jam packed day. Here are my notes from the sessions I attended.

Keynote – Elevating the Agile Community of Thinkers 

Jean Tabaka presented this keynote, barefoot, and her slides are available here.

From Agile Australia 2011
  • A Community of Thinkers” – drafted by Liz Keogh, Jean Tabaka and Eric Willeke
  • need to apply energy to learning rather than frustration – need to subscribe to the art of the possible
  • it is no longer acceptable in the 21st century to administer in the business, we need to create and provide innovative communities
  • fearful that in the agile community that we are in conflict mode but rather we should seeking enquiry and insights and learning from each other, such as we do in an daily standup
  • to be the best we can be every day, we need to inspire insights from the entire team – the definition of a good daily standup
  • Patrick Lencioni’s “The Five Dysfunctions of a Team” also apply to community
  • “vulnerability can create great workplaces and innovation” (Dr. Brene Brown)
  • our greatest wisdom is every insight in the room and is only as good as the quietest voice in the room – we have to lower the bar
  • in a command and control environment we lose wisdom and lower their IQs
  • in global teams you need to invite their wisdom in anyway possible – secret to distributed teams
  • Kathy Sierra – magic for Creating Passionate Users
  • drop outs give up when they believe they suck
  • amateurs learn how to do it and then become complacent
  • experts – keep pushing themselves to find a better way
  • in agile need to believe past both the “this sucks” and the “kick ass” threshold
  • we need active participants in our communities, rather than passive participants
  • Linchpin (Seth Godin) – being a genius self, being part of community means hard work
  • Principles of Product Development Flow (Donald Reinertsen) – this and Linchpin are Jean’s most dog-eared books
  • empathy mapping ( – look at your community and what are they thinking, hearing, saying, doing, seeing
  • use a wall of appreciation as well as a wall of break up letters to improve community and move past blockers
  • writing love letters to agile – interesting…
  • to be a linchpin your message needs to be accessible (charm), need to create talent around your message and have perseverance
  • “Drive” (Dan Pink) – autonomy (able to bring your genius self to work), mastery and purpose (a big hairy goal) – you will be creative
  • need to design a life and not a plan – how can we grow and be emergent in what we do, plans stagnate and stagnation kills
  • “Preferred Futuring” (Lawrence Lippitt) – create concrete wishes on where we want to be, need to bring this more into our workplaces
  • need to move – tell -> sell -> test -> consult to co-creation
  • find your mentor, or become that person
  • think like a genius – creating models of what might be true
  • example of Rally using lino to organize an open space – awesome
  • Jean not wearing shoes in this keynote is going out of your comfort zone –

Panel – Software Engineering is a Dead Craft

I was honoured to be given the opportunity to moderate this panel, consisting of Martin Fowler, Kane Mar and Paul King. My opening comments were as follows:

Software Engineering is defined by the IEEE is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.

This led me to then get a definitive definition of engineering, which is loosely defined by a number of the leading engineering councils worldwide as being the discipline of acquiring and applying scientific knowledge, mathematics and ingenuity to design and build solutions that safely improve the lives of people.

Software engineering as a term has been around since the early 1960s, and, as Rob Thomsett pointed out in his keynote yesterday, was popularized when NATO hosted a conference to address the problems of software development. In there report, they particularly point out that the phrase software engineering was deliberately chosen to be provocative. So for the last 50 years, practitioners everywhere have been debating software engineering, from the software crisis that made developing software into a career, through to Fred Brooks coining the No Silver Bullet argument that no individual technology would make a 10 fold improvement in productivity in 10 years, through object oriented programming and the rise of XP and agile.

So what is software engineering. Is it an engineering practice that is dead? Is it a craft or an art form? Or is it both dead and a craft?

Martin Fowler is the Chief Scientist at Thoughtworks, author of many books on software development and a signatory to the agile manifesto.

Kane Mar is the President of Scrumology, and has been a developer and coach in the software industry for 20 years.

Paul King is the Director of ASERT and has been developing, training and contributing to the software development field for nearly 20 years, and is an active contributor to a number of open source projects including, most notably, Groovy.

My questions started as follows:

Martin – when you do any Google search on software engineering, every second link seems to point back to your website and any number of articles you have written on this subject over a number of years. You indicated your position is that the engineering metaphor has done our profession damage…

Kane – you listed your point of view on the topic is that the paradigm has come and gone and that perhaps software should be viewed as an ecosystem…

Paul – your viewpoint is listed as probably a little more conservative and that continuous learning is important…

The time flew by and I did not get to take anywhere near the number of questions I would have liked from the audience. The highlight was a question from the audience from Phil Abernathy who asked the panel if perhaps we should term what comes out of a number of projects as “crapmanship”.

Agile and Enterprise Architecture are not Mutually Exclusive

I had the pleasure of introducing Rebecca Parsons from ThoughtWorks, her slides (in all their Comic Sans MS glory) are available here.

From Agile Australia 2011
  • architects need to depress their ego and pair on critical stories and calm their concerns
  • some architects believe their job is to stifle any innovation in the development team, but they a disappointed that the team is not innovating
  • the IDE of enterprise architects has been PowerPoint for years
  • developers must code in a box, architects must worry about a bigger box
  • it is hard for enterprise architects to talk to every developer, so documents from high are standing operating procedure, unfortunately they get ignored because the context is hidden
  • use stories for technical requirements – architect communicates his requirements via a technical story and the development team responds with this is what it is going to take – ensures that the value is articulated
  • need architects to articulate their requirements based on acceptance tests
  • harvest components and talk in the community – ask who was the last person to integrate with this component and talk to them
  • development team should be focussed on delivery of their project, agile is the engine and architects need to use this engine

The Speed to Cool: Valuing Testing and Quality in Agile Teams

The session I presented got a good turnout, and plenty of questions afterwards as well as some follow-up emails.  The slides are available in a separate post as well as here.

From Agile Australia 2011

Rolling Out ‘Agile principles’ in a Global Organisation – A Continuous Journey

I introduced Sascha Ragtschaa from Computershare, his slides are available here.

From Agile Australia 2011

A Rogue’s Take on the 4 ‘C’s: Culture Change Costs Currency

I had the pleasure of both introducing and being a live prop (the dragon representing the (large) organisation) in this presentation by my good friend and colleague Renee Troughton from Suncorp. Her slides are available here.

From Agile Australia 2011
From Agile Australia 2011

Keynote – Software development in the 21st Century

Martin Fowler delivered his now famous 3 short keynotes.

From Agile Australia 2011

Non-Determinism and Testing

  • non-determinism – intermittent fails, we don’t know if something is going to succeed or fail – also called a useless test
  • non-deterministic tests infect the whole system – need to quarantine these tests to stop them bringing down the while suite – often caused by interference between tests
  • you can track dependencies or you can use isolation (preferred method)
  • tests should clean up after themselves and leave the world the way they found it but other tests rely on this happening (and hard to track failures when they occur) or start all tests with a clean slate (but it can take a long time)
  • asynchrony – can use a bare sleep but you never know how long to sleep for, could use a polling loop or a callback
  • remote services – don’t talk to them as part of the test, use a test double

Value of Software Design

  • this was a repeat session from last year where Martin did his famous Uncle Bob Martin rant. A highlight for me was in his example he used Nigel Dalton as good code example and me as a bad code example.

Agile Manifesto: 10 years later

  • we know the approach works and we need to use it more and find the boundaries
  • XP was the dominant strain at the time – has appeal of its values and principles as well as its practices like test driven development, etc…
  • many of the original people are unhappy – the core ideas have not moved as fast as the hype (semantic diffusion) and the rollout process is very long running
  • if you say you don’t care about agile you are saying you are happy with flipping the principles back again
  • do not treat stories as one-way traffic, the value is in conversation
  • as software developers we need to ask ourselves if we are making the world a better place
  • mundane work and the little things often make the world a better place

Conference Retrospective

I led a conference retrospective after the post-conference drinks. For those who stuck around, we had a good discussion on what was good and what we could do better next year.

What Was Great

From Agile Australia 2011
From Agile Australia 2011

How Can We Improve

From Agile Australia 2011
From Agile Australia 2011

New Ideas

From Agile Australia 2011
From Agile Australia 2011

Other Stuff

There have been some other wrap-up and retrospectives written about the conference including:

Also, a couple of mentions for some of my other friends and colleagues who presented on day 2 but due to my other commitments I could not attend their sessions.

Jonathan Coleman, Steve Jenkins and Phil Abernathy all did lightning talks which were all well received.

Nicholas Muldoon from Atlassian delivered a talk called “Be The Change You Seek”, his slides are available here.

Paul King (who I have presented with many times previously) delivered a workshop called “Leveraging Emerging Technologies in Agile Teams”, his slides are available here.

Agile 2009 Day 1 Review

Agile 2009Once again I was extremely lucky to get two talks accepted at Agile 2009 (with Paul King) and the support from Suncorp to send me along to speak. Whilst its a been quite a number of weeks since the conference, I wanted to ensure that I posted my notes and comments. This year, being my second attendance, I found the hallway discussions all the more valuable and had many awesome conversations with friends made last year as well as new friends just met. Added to this, Chicago exceeded my expectations as the host city.

Once again, the number of simultaneous sessions made the decisions extremely difficult on what to attend.

The sessions I attended on day 1 were as follows:

Using the Agile Testing Quadrants to Plan Your Testing Efforts

This session on the testing stage was delivered by Janet Gregory, one of the authors of Agile Testing. The slides are available on the Agile 2009 site.

Testers should be part of release planning and think about:

  • scope
  • test infrastructure and test tools / automation
  • how much documentation, is it too much, can I extract it from somewhere

Iteration planning:

  • plan for done, acceptance tests
  • priorities of stories, which stories to do first, connect with developers
  • budget for defects unless you are a high performing team

Need to acceptance test the feature, not just the story.

We then did a collaboration tools exercise, and some of the tools used by the audience were:

  • desk check / show me – when a developer thinks they have finished coding, get together and take a look
  • wikis, conference calls, GreenHopper, etc
  • daily standup – share when things are done, if you find them ineffective
  • project cards – used for story management and documenting conditions for acceptance
  • sticky notes and pens for a co-located team
  • demonstration every week or end of every iteration
  • FIT tool, used for demos
  • walking and talking
  • pairing
  • generated artefacts from the CI server
  • instant messaging
  • puzzle / chocolates on desk to encourage talk, “free to developers if they come and ask a question”
  • rolling desks on wheels, so they can switch configuration
  • rolling whiteboards
  • JIT (Just In Time) meetings as required
  • mind mapping software that hooks up to Jira
  • retrospectives
  • team review story and write tests together
  • nobody said “email”!, no email!
  • recorded chat room, so conversation is recorded

Waterfall test pyramid, upside down, very unstable – Functional Tests –> API Tests –> Unit Tests (heavy functional tests based on GUI, very few unit tests).

Automated test pyramid (Mike Cohn) – unit tests / component tests are the base layer, require testable code that we can hook into below the GUI at API layer, GUI tests are most brittle because UI changes so do as few of these as possible, right at the top you might need a handful of manual tests.

Agile testing quadrants change the way you think about testing – use to classify tests, what the purpose of the test is (why are we ariting these tests), tests will cross boundaries.

Agile testing quadrant – can be used as a collaboration tool (developers will understand how they can help), emphasizes the whole team approach (no “pass this to the QA team”, whole team is responsible for testing), use to defne doneness (use for planning, what needs to be done, has estimate allowed for the amount of testing we wish to complete).

Quadrant 1 – technology facing tests that support the team, TDD supports the design of the team, tester has feeling of comfort

  • unit tests test the developer intent, individual tests on a method, small chunks of code, fast feedback mechanism, code is doing what it should do
  • TDD tests internal code quality, if developers test correctly it flows all the way through and makes easier to test functionally
  • base for regression suite, if you are going to spend any time on automation, “put it here”, return on investment is better the lower you go in the pyramid

Quadrant 2 – where the acceptances tests live, supporting the team in natural language, helping the team deliver better software, use paper prototypes to talk to customers rather than big GUI, acceptance test upfront helps define the story, use examples to elicit requirements (easiest way to get clarification from the customer, always ask “not sure what you mean” or “give me an example”, pair testing (ask for feedback as soon as possible)

  • the examples can become your tests, write upfront and ensure that developer makes them pass when they develop code, use tools such as Fit / Fitnesse, Cucumber, Ruby / Watir
  • examples help customer achieve advance clarity, focus on external quality (facing the business), want the tests to spark a conversation with the developers
  • BDD use of given (preconditions), when, then as opposed to tabular formats in Fitnesse, useful for workflows
  • Janet polled the room and only about a dozen people in the room give their acceptance tests to the developers prior to the story being developed
  • if no automation tool, write up a manual sheet, give it to the developers and have a conversation before the card starts

Quadrant 3 – user acceptance testing, critiquing the product, getting the customer to look at the system

  • exploratory testing – time box these sessions to reassess about how far you wish to go, following instincts and smells with a purpose, touring (eg. the money tour) as defined by James Whittaker and James Bach (in the book Exploratory Software Testing), this is where you find majority of bugs so testers should spend the majority of their time here (which is why you need a good base of automated tests)
  • collaboration testing – forge a relationship with the developers so you know what they are developing,
  • remember your context to determine how much testing is enough (eg. mission critical software vs an internal application)
  • attack stories using different personas – Brian Marick likes to create evil personas (eg “pathological evil millionaire”) or use impatient internet user vs grandma who clicks every link on the internet

Quadrant 4 – non functional tests (should be part of every story (eg. is there a security or performance aspect), ility testing, security testing, recovery, data migration, infrastructure testing, do as much as possible upfront although sometimes you will need environments that will not be available to the end

  • non functional requirements may be higher than fucntional (eg Air Canada seat sale might need critical performance)

Test plan matrix – big picture of testing against functions for release, usually on a big whiteboard, use colours (stickies) to show progress, benefit is in the planning in what we need to do testing wise but also appeases management because they like to see progress, gives idea of where you are going

Can use a lightweight plan, put risks on a white page, 35 of the 37 pages of the IEEE test plan are static, so put that information somewhere else

Test coverage – think about it so the team knows when the testing is done, burn down chart will be enough if you test story by story, when thinking risk ensure you include the customer (they may have different opinion of risk


  • think big picture – developer following a GPS only needs to know next 2 weeks, but tester is a navigator and needs the map
  • include the whole team in planning and test planner
  • use the quadrants as a checklist (put them on the wall)
  • consider the simplest thing, especially in relation to documentation
  • think about metrics – one man team might be good enough to just know they passed
  • visible, simple, valuable

Janet also mentioned the following throughout the session:

I also stumbled across a related blog post on this session at:

What Does an Agile Coach Do?

This session was delivered by Liz Sedley & Rachel Davies, authors of the new book Agile Coaching. The slides are available on the Agile 2009 site.

This was a hands-on workshop and involved some good discussions on how to deal with different coaching scnarios.

Zen & the Art of Software Quality

This session was delivered by the legendary Jim Highsmith. The slides are available on the Agile 2009 site.

  • “There Is No More Normal” – John Chambers, Cisco CEO, Business Week, 2009
  • business strategy needs to be more adapting to change than performing to plans
  • mixed messages – be flexible but conform to a plan – dilemma faced by many agile teams
  • Artful Making” – Rob Austin – describes $125 million software failure
  • 1994 there was 82% software failures, 68% in 2009 (success defined as on time, on budget, all specified features) – Standish is measuring the wrong thing, not a good measure
  • cancellation of a project should not be a failure, it is a good thing
  • current environment – schedule is more important than value
  • Beyond Budgeting” – Hope/Fraser – not a good book, but good ideas
  • Measuring & Managing Performance in Organisations” – Austin – all measurements are dysfunctional, get a different outcome than you expected
  • if budget 100 and you achieve 100, better than budget is 120 and you achieve 110 – which would a performance management system reward (the 100, even though latter is better achievement)
  • beyond budgeting – make people accountable for customer outcomes, create high performance climate based on relative success amongst others
  • trust, honesty and intentions are better than measurements
  • performance tends to improve while people figure out the system, but under pressure people focus on measurement goals rather than outcomes
  • earned value (time + cost) has nothing to do with value, does not have anything to do with what is delivered to the customer
  • we need to move from scope/cost/quality to value/quality/constrants (scope/cost/schedule)
  • core benefit from agile has been value and quality
  • everybody comes to work to do good quality, but never well defined
  • Zen & The Art of Motorcycle Maintenance” – Pirsig – quality ideas
  • is quality objective or in the eye of a beholder, people have different ideas
  • need extrinsic quality (value) and intrinsic quality (so you can deliver quality tomorrow)
  • Applied Software Measurement” – Capers Jones  – 95% defect removal rate the sweet point for quality
  • experience is doubling staff quadruples the number of defects – BMC were able to kick this trend using agile
  • difficult errors take time to find – longer the worse quality of the code
  • first year of product release the quality might be OK, but then adding new features more important than fixing software debt, over time the cost of change increases and accumulated technical debt harder to fix, but the more debt the higher the pressure to deliver
  • strategies – do nothing, replace (high cost/risk), incremental refactoring, commitment to innovate – best way but hard to sell politically – downward cycle from vicous cycle to a virtuous cycle (55% said easier to support agile developed products)
  • productivity in features you don’t do, 64% of software features never used, what if we put 25% of that money into refactoring or leaning agile
  • agile value curve – if doing high value first we can ask the quation do we have enough to release the product?
  • need to reduce the margincal value of our stories
  • if you don’t have time to estimate value, you don’t have time to estimate cost
  • philosophy – value is an allocation not a calculation (cost is a calculation), so use value points and allocate from the top down – value points need more thought than ranking – additional information when you look at 25 story point card worth only 2 value points, also demonstrates that value is important, should be able to do this fairly quickly
  • value and priority are different – a low value card high on priority might be a guide, pick a cap for the value
  • value points like story points are value
  • story point is calculation of cost, value point is allocation of revenue
  • Intel has 17 standard measures of value, help to determine as a guide
  • value in Chinese means smart/fast
  • value – is product releasable – always ask the business owner or product manager that question – example that a product could be released when it was 20% complete
  • parking lot diagram – empasizes capabilities we are delivering to customer in their own language, show progress and value deliverd by number of stories done / done
  • Gantt chart shows task complete to a schedule
  • questions – can we release, what is value-cost ratio (do we need to continue or do something else that is higher value), what is product quality, are we within acceptable constraints
  • how do you determine if you are in a technical debt hole – using qualitative measures in your code
  • ask the queston – do you know why it takes 3 months to make a change, explain the technical debt curve, start to show people that quality matter (eg. automated testing becomes a time accelerator)

Ice Breaker & Freshers Fair

The Fresher’s Fair at the Ice Breaker had a number of great groups including Kanban, Usability and CITCON. I stumbled across the following poster that was a long way from home…

Agile 2009 CITCON Brisbane