Day 4 at Agile 2011 brought a full day sessions full day of sessions followed by the conference dinner. For the first session I used the law of two feet and landed in three different sessions.
Stages of Practice: the Agile Tech Tree
Arlo Belshee and James Shore led this hands on session to build a technical tree of agile practices. I didn’t stay for long, but I was interested in the output, which I found hanging on the walls later in the day.
Steve Denning (author of a large number of leadership books) delivered this presentation based around a blog post of a similar name that I sat in for about 30 minutes. His presentation is available here.
delight is happiness, joy, customer success – everybody has a story or understands this concept
identify your project that you wish to delight – who is your customer?
what do customers say they want? – warning! they don’t always know eg. New Coke
what is it that core customers might not like about your product? eg .why they made the Nespresso machine because people did not like cleaning up, need to get inside their head to understand what you need to change
Agile From the Top Down: Executives Practicing Agile
Jon Stahl delivered this session, and I wish I had been there for this one all the way through as his presentations are always entertaining and informative. His slides are available here.
get HR to create their own room to map the organisation and look for patterns – finding the truth isn’t simple but putting stuff on walls creates conversation
create a tool wall – who cares what tool you use, as long as you are adding value
get the practice vocabulary up on the wall – matched with a booklet with more detail
when tracking practices move away from traffic lights and use smiley faces to track how people are feeling – don’t care about if they are doing stand ups but how are they working for them – good way to figure out where to send coaches, where the frowns are
transparent leadership – post and show your people what roadblocks you are working on
everybody wakes up everyday thinking they are doing the best thing they can – as a business the executives need to check each other to make sure they are working on the most important thing and allow each other to question
Relish – the only way the customer will read Cucumber tests
two way mirrors – ensure the users are integrated into development and they can use the software, outside the building
good coders find stuff hard – easy to Cucumber test the full stack but the build time blows, unit tests are hard but are fast, so limit the amount of cucumber tests and isolate them
features rot if the Customer does not read them or not exposed via tools like Relish
manual testers duplicate automated tests – expose features, pair, give Cucumber ownership to QA
how to test lots of permutations – pairwise testing is OK, or just automate the happy path and one scenario and manual test the rest
metrics – JUnit Max to predict probability of failure
Limited Red – calculates the probability of Cucumber failure to improve the way we work – found features that never fail – just keep them in nightly build – means a long build usually fails very quickly
use JMeter to check everything is up like a tracer bullet – eg. a row has appeared in a table
got 8 hour build down to 20 minutes by distributing over 24 EC2 nodes – but think we were solving the wrong problem
slice up the architecture and have thin tests to test them
Spork – helps to speed up the start up time of an application – hard to know whether to reload and it adds a lot of overload at the protocol layer, so almost as efficient to run the tests
people have core responsibilities but we all meld in our roles to be one team and deliver
I enjoyed this session, particularly as I read about Joseph’s company in Specification By Example. I am excited about the prospect of a tool such as Limited Red as well.
Telling Better Stories with User Story Mapping
Jeff Patton led this session to a packed room that included a live appearance from his children! His slides are available here.
how to change the world – start with an idea which is product > feature > specification > requirement
learnt that requirement means “shutup just build it”
outcomes result in impact – agile is to maximize outcome and impact we get
stories are a conversation about the future
stories are 5c’s – card –> conversation –> confirmation –> construction –> consequences (when we realise our ability to predict the future sucked!)
Kent Beck called them stories because they were meant to be heard
need to figure out the who, what, why – this is the richness behind the story
add a short title, add a description (story template), add notes, specifications and sketches and write acceptance criteria before writing software
stories shrink in size and grow in detail as they travel through a pipeline
start with capabilities or features (understand value) –> break to release size stories– > upcoming iteration stories (priority, UI design, business rules) –> break to iteration size stories (details user acceptance tests, small enough to fit in iteration) –> completed bits of software
user story mapping – based on story mapping in films
ultimately we have big things that break down to little things
Build story maps by:
talking to real users
brainstorm user tasks to help them organize
research and build from a narrative
discussions with users in front of a map drive out conversations
plan incremental releases as a team event – developers will actually read the plan
start talking about adding stickies and notes, finally get a fist of five for confidence
don’t prioritise user stories by ROI – target a user segment
like ripping a $5 note, the small stories are not valuable (Jeff actually ripped a $5 note to illustrate the point)
Finally, Jeff has a User Story Mapping book in the pipeline which looks really interesting. I have had the pleasure of meeting Jeff a few times and always enjoy his presentation and learnings, and I am keen to give these learnings a go in my next storycard workshop.
Flirting With Your Customers
Jenni Jepsen delivered this presentation, the slides are available here.
We started with an exercise – 3 things that make a great project – trust, hard work, common goals, transparency, clear direction, grown ups, togetherness, support, communication, budget, right skills, creativity, quality, teamwork, fun, support
We then discussed 3 things that make a great romantic relationship – trust, communication, clear expectations, respect, common goals, honesty, integrity, similar values, enjoy spending time together, depth, support, compromise, patience, back rubs, teamwork, equality, chemistry, humour, passion, sacrifice
there is a lot of commonality between projects and a relationship
flirting is about making people feel valued
need human touch to thrive, keeps immune systems strong
people who are happy and feel valued at work results in increased profit
introverts need to take care of themselves, take energy from within – they can flirt but it takes energy
extroverts thrive in social situations – if your customer is an introvert they may not share your energy
The 8 steps are:
radar – makes you aware of the people around you, takes confidence
target – figuring out who you want to connect with in an organization, who has the real power
move in – show interest, practice your opening line – make eye contact, making the person feel like they have knowledge, makes them feel valuable, interactions become richer because of this
back off a little – the other person may not be ready for the interaction, give the other person space
open up – being honest and laying it out, you have now created a comfort zone, you are also making yourself vulnerable, there might be some back and forward bargaining here
dance – have a little fun, create conversation – lunch, cook together, virtual coffee over Skype, celebration to mark a milestone, dinner club
get real – go through a crisis together, if you have flirted and built a relationship
enjoy – enjoy the relationship
have a list of questions to get over the anxiety
all good steps for people you manage
body language is 93% of communication
Conference Party
The conference party was entertaining as always. Here is me hanging out with Alan Bustamante (who I worked with on the reviews) and the gang from Seapine Software
Scaling Software Agility: Advanced Practices for Large Enterprise
Dean Leffingwell is the author of Scaling Software Agility (which was written in 2006 and, in his own words, the world has changed since then) as well as Agile Software Requirements (which is really about portfolio management). Dean presented this session, a copy of his presentation is available here.
scrum is designed for small teams and makes no claims for scale
scale might not work, you can make it work
economics and technology have changed to make agile work
Not everything is a user story:
user stories came from XP, builds the user right into the requirement
lots of teams have their own stories in their own sprints
if something is in the backlog we might do it, if it is not in the backlog we won’t do it, anything that needs to be done goes in the backlog
best code comes from XP shops – it’s a form of hygiene, like brushing your teeth
the user story model lacks context – the things around it
at enterprise scale you have a large, large amount of stories but how do you reason about that and get the context
we need an additional level of planning – features which get decomposed into stories
features need to fit into potentially shippable increments as well, because they need to ship
stories need to get tested, as do features and non-functional requirements
use epics to describe features that are too fine grained at the enterprise level – may be implemented over long periods, even years
investment themes represent the budget allocations that drive the authority – at a program level figure out your epics that make up 17% of the budget, for instance
Think agile programs, not just agile teams – manifesto does not mention teams at all
there are lots of teams in the enterprise
need to train everybody, but that is slow and expensive
regular release train, build it this way even if if the customer / factory is not ready for fit
change value system from plan driven to value/vision driven – move from Clarity driven estimates which we then fix to fixing a date which we strive to meet
in software industry we always miss dates, build credibility by meeting dates
most teams are overly optimistic
quality needs to be built in, but features need to be variable
everyone needs to be on the train – waterscrumming does not work
hindsight brings us perspective
cadence alone is not enough – worst nightmare is not the facts but the false sense of security that you are going to deliver
slowest component drags the train – if you have a VP of system integration you are already screwed
make sprints the same length – two weeks is a good cadence, three weeks is too long, you can’t figure out when you should start testing
have regular system wide integration – use PSI (potentially shippable increment) to ensure you have a product, use hardening sprints for the things you can’t do in a normal sprint and let the team catch up
release train process – when you have an asset that adds customer value, ship it or ensure you have a asset that you could ship – it could save you with large maintenance renewals
pacemaker is release planning – need a full day or two for release planning – if you can’t spare that then plan badly – also gives us full alignment, a good point to get the architects involved because at this point you can make a change – plan using stories because that is the teams currency
scrum gave us a framework for sprints – plan and commit on day 1, execute for 8 days, demo and retro on day 10
at enterprise level raise this to the PSI level – plan and commit at the program level and demo and retro together at the end, sprints at team level in between (a program is usually 5-10 teams)
do a one week all in training for the team and then fire straight into release planning – then coaching is in context – don’t have good experiences with teams that go ahead without coaching support
take into account that your first sprint will be a little rough
Enterprise systems require intentional architecture – it matters!
refactoring is part of agile, list on the wall and get the product owner to stand by them, but it doesn’t scale very well
architecture can emerge, you can’t always plan for it
principles of system architecture are important
the architect needs to be part of the team to succeed
the team owns the design of the system, gives them accountability – design spike is our currency for architecture and it needs to be demoed
sometimes we need architectural epics – architectural epic kanban system
Portfolio management must be agile too – the mothership of all impediments!
PMO is governing us to a model we have abandoned, yet we created it in the first place
need to move from a portfolio of projects to a backlog of content management
need to move from cost estimation to velocity estimation and planning – so estimate your releases and epics in points too, not in dollars or hours
the team manages a project, not a traditional PMBOK manager
Overall, there was nothing really new in this session for me, although it was great to hear from Dean directly, especially on the topic of PMO’s and leadership. His latest book is still on my list to read.
Removing Impediments with Drawings
Carlton Nettleton led this interactive session, the instructions and agenda of the session is available here.
A drawing is more memorable, particularly when related to a story, helps your audience visualize your message, pictures drawn by a human are better than those drawn by a computer because they look too perfect
SQVID is a metaphor of how to draw pictures. Are you drawing:
simple or elaborate pictures
quality vs quantity
vision vs execution
individual vs compare
change vs status quo
Imagine:
discuss why you are imagining
draw simple
don’t overwhelm by drawing too much
iteration and refinement
think outside the box
Show:
focus on the audience
feedback
evolution – start, middle, end
outside perspective
drawing is only for support
This was a very hands on session, and the charts that we used in the exercises were very good templates that I will recall and use in future. The takeaway for me was to draw pictures in real time more to illustrate and get engagement for my message. I will also take another closer look at Dan Roam’s book.
Agile 2.0 – Rebooting A Raccoon In An Imperfect World
in lean 99% of behaviors are driven by the system – people were driven by the situation at hand
focus on behaviors not values or judgements
Formula:
be specific on timeframes eg yesterday
your observed behavior
perceived impact
recommendation or suggested solution
make it a conversation – set aside time such as feedback frenzy Friday
give feedback earlier, not just at annual review time
create safety – “is now a good time”, not a public theme but in private
seek clarifications – apply the five why’s to feedback
say thanks for feedback at the end – appreciate being helped to grow
take action on the feedback
Overall I have always found Patrick’s writing on retrospectives helpful, however there was little new in the presentation for me.
After Dark
Wednesday night was the Sponsor Reception, where the prime aim was to get to every booth and get a sponsor stamp (the real rule was to get one stamp per page, but it was far more fun ensuring I visited every booth!) One of the amusing things in Salt Lake City was that they do not take themselves too seriously, as evidenced by this beer.
Day 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
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:
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
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
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
get your ideas out there and blog it, tweet it, present it
Warnings:
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.
It was great enthusiasm that I set off to Salt Lake City last month for Agile 2011. In the lead up I was a reviewer on two stages (Testing & Quality Assurance and Working with Customers), plus I was lucky enough (and apparently the only submitter) to have all three of my original submissions accepted (although conference rules, for good reason, restrict speakers to two sessions). Whilst its a been a month since the conference (I took some time afterwards to spend time on both the east and west coast of the USA), I wanted to ensure that I posted my notes.
Here are the notes from the sessions that I attended on day one.
The Product Partnership: Using Structured Conversations to Deliver Value
Mary Gorman and Ellen Gottesdiener led this tutorial. They started by taking about requirements by collaboration and leading a discussion on things that hinder and help.
Things that hinder: access to the right people, thinking about the solution rather than what needs to be done, multitasking, people not listening, customer not clear of needs, backlog too big, stories too big, missing product owner
Things that help: centralised repository, short backlog, story maps, clear business goals, UI mockups part of the story, clear priorities, crisp acceptance criteria
conflicting voices for value – not just from the customer but technology value, we need to listen to all the voices
evaluate requirements – value, risk (such as technology risk, team risk, outsourcing risk) and dependencies (dependent on other teams or external vendors and requirements and dependencies where value violates the way we would like to build the system)
benefit – IRACIS (increase revenue, avoid cost, improve service) needs to be balanced with cost, time and delivery
table stakes – the things we must deliver to stay in business
differentiators – point of difference in the marketplace
two states – credible (it has some kind of value) or buildable (it has been prepared and is sliced, groomed or right size as well as understood well enough to estimate, test and document)
incorporate UX into preparation, collaborated workshops
slice for value – starts with a glean in someone’s eye, then it gets bigger because we have a bunch of options, so we need to fit based on value to contract the list
Data: Fee
Type options: regular, early bird, super early bird
State options: available, sold out
Data: Payment
Type options: credit cards, payment order, check
State options: paid, pending, not paid
We may also visualize this as a data model or a state diagram
Once this is complete we can now we slice for value and write a story. This needs to be the silver bullet / tracer bullet, then you can break down from there. At this point you can write the stories and throw the sheets away. This all leads to:
As a... I need... so I (value)
Requirements leads to examples which leads to tests. We can now link this to given when then:
Given: pre-condition (state), fixed data
When: action, business rules, input data
Then: output data, post condition (state)
It is recommend that you come to these workshops with some pre-planning but be under the agreement that they are draft and often wrong. These could be release or iteration planning workshops.
Now the forgotten heroes, the non-functional requirements:
design and implementation constraints – the givens, the parts of your technical infrastructure that are dictated or restricted – worth pausing and discussing if there are any options
interfaces – human, other systems and device interfaces such as messages (you could use a context diagram to illustrate this) – with the diagram you can start discussing the options / choices / possibilities
quality attributes – things like speed, stability, uptime, security, scalability, usability, extensibility, etc…, need to be testable and SMART (specific, measurable, attainable, realistic, time-based) – eg. recover from user error in x clicks, x time
You can do this at the big view (business process, features, MMF, scenarios), pre-view (user stories, user story maps where you lay out stories left to right, scenarios) or the now view (buildable, scenarios). The granularity will change.
Need to have a structured conversation to communicate effectively. Face to face is the most effective and get a shared understanding of the highest value.
Overall, this was an enjoyable session. I really liked the templates for mapping out the requirements (despite the fact that these were essentially just aids for the workshop) as they helped focus the conversation and gave our group something to focus on. Mary and Ellen are currently writing a book based around this content, so I look forward to seeing that in the future.
Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership
Christopher Avery (creator of the Leadership Gift and author of The Early Admissions Game: Joining the Elite, which apparently is 10 years old and still in print) led this extremely packed session, the essence is contained in this publication available here (as well as here).
We started the workshop by competing in a spaghetti challenge (based on the Marshmallow Challenge) which consisted of the materials of just 10 pieces of spaghetti and a line of tape. The team I was working with constructed a tower of 35 inches, which ended up being the second tallest in the room.
There is a pattern in our mind that kicks in every time something goes wrong – creates angst and anxiety – responsibility process – a descriptive model:
QUIT – the pressure of responsibility and obligation can lead us to quit, an avoidance move, a lack of completion, active disengagement
RESPONSIBILITY – call yourself on obligation so you start looking for solutions – start saying “I get to go to this stupid meeting”, means you have a choice – we were taught that doing stuff we have to do makes us responsible
OBLIGATION – I have to go to his stupid meeting have to but don’t want to – leads to resentment
SHAME – how could I do this, how could I be so stupid – laying blame on self – premise is the problem, you can’t learn
JUSTIFY – it was raining, I dropped my keys – story makes it just – “that’s just the way it is around here…”
LAY BLAME – who took my keys? – not a solving position of mind
DENIAL
3 keys – descriptive model
INTENTION – wanting to get something done, get to RESPONSIBILITY around every problem in your life
AWARENESS – be aware of which level you are in
CONFRONT – ability to face, taking yourself to the edge of your comfort zone, comfort zone = current capability, confront = expanding capability – every person you know was once a stranger
Example coping mechanisms are: learn to live with it, it worked on my machine, they just don’t get it, it’s the vendors fault, it’s too hard, you’ve been here long enough to know that’s not going to happen, murphys law, we did exactly what they asked for, …
We then did a “Be With” exercise, which was essentially sitting knee to knee with the person next to you, in complete silence, for 30 seconds, to feel the others anxiety. Ultimately, it’s not the other person that makes you feel bad, it is yourself.
Confront is the angst of confronting yourself. If you want to change something you need to poke it, and observe the change.
Accountability Responsibility:
accountability is the number one tool of management – it’s the way we manage commitments between two parties – its outside of us because it is us and someone else
responsibility is about how we respond – internal to us, and different for all of us
what people are signed up for is greater than what they are responsible for
what people are responsible for is greater than what they are accountable for <– We want to be here
they are both equal
Where’s the bottleneck?
what if you had to reproduce the code, if you had the same team and resources?
what percentage would be more efficient the second time?
modal is 70%. You would be better because you have solved the problem before. Learning takes time. Essence of agility is to learn and take feedback.
There is lots of feedback in agile practices such as retrospectives, showcases, standups, etc… If you are not going to do anything about it, stop investing in the feedback loop. The fastest way to learn is to take ownership.
Fastest way to elevate responsibility in a group is demonstrate it yourself. If you are saying people around you are not displaying responsibility, then you are just laying blame.
Exercise coaching responsibility. The responsibility process only works when it is self applied! You need to teach it so others can self apply it. Counter not being good enough yet to teach this yet:
Give yourself forgiveness, forgive yourself for being human
Teach this with a light tone. Make yourself the brunt of all the jokes that are below the line
Don’t go into agreement (“but I do have to go into that stupid meeting”) – don’t confuse the facts with the mental position – take time, breathe, count 10 seconds and answer – validates they raised a good question and allows you to respond – ask if you can push back on them a little bit, and ask them to identify where they are on the chart
Make sure you support – need to forgive yourself, let go and move onto a better future
Taking responsibility is owning your power and ability to create, choose and attract.
Responsibility is the design space. What do we want from this? Be clear with what you want and be clear about the consequences. Responsibility gives you power but also potential consequences.
There is a difference between choosing something and avoiding something.
As a coach you get to intervene in situations, so you need to act from a position of responsibility and check where you are coming from (move through the model as quick as you can). Ask yourself if your message is clear and does not sound like blame.
Advice is seldom effective so stop giving advice. You are transferring responsibility from them to you. If it doesn’t work they perceive it as being your fault. Instead:
Resist giving advice. Tell me what you have tried, tell me what you haven’t tried
If you must give advice, give three alternatives so they have to choose, putting responsibility on them. “If I were in your shoes I might consider a…, b…, c… What do you think about those?” One coaching company advises 10 alternatives, so you really think about the responsibility.
Finally, play the “Catch Sinner” game to learn the process:
make a score card
choose a word for today
make 2 columns – “get off of it” and “it got out”
throughout the day, everytime you catch yourself in a position of “blame” mark your chart
10 points for the left and 1 point for the right column
build tremendous awareness for each word at least for one day
There are a bunch of resources at Christopher’s website, in particular he encouraged us to get a copy of the teaching poster and empowered us to teach the process to our peers.
Overall, I really enjoyed this session, as I had heard good reports from this session when it was help in 2009, and this year it was listed as one of the most popular sessions. The responsibility process is something I would really like to work on personally.
The Agile Manifesto 10th Anniversary Reunion: The Big Park Bench
This was one of the highlights of the conference where 15 of the 17 original authors of the Agile Manifesto got together on a big park bench to discuss the writing of the manifesto.
Jim Highsmith noted that there us nothing about it that he would change and would not get back together with these people to do it!
Ward Cunningham would change the colour balance of the background image
Brian Marick noted that individuals and interactions can often be a beat up for people who appreciate tools
Jim Highsmith commented when asked about the next 10 years that agilists don’t predict!
they never expected that something written in a couple of afternoons would be this big
Brian Marick recalled that the stated objective of the meeting was a manifesto and it seemed miraculous that they left with a good framework . Bob Martin was just surprised that he has been to one meeting that worked!
Martin Fowler did not want to call it agile, he wanted a wackier name
Agile Manifesto nailed it as a baseline – they might have added “we really mean it” or “we are not kidding”!
when you gel with a team you get what can be summed up in 3 words: high quality work
great teams change people lives. “The manifesto changed our lives, and probably yours too”
many people who may have survived under waterfall may not survive much longer under agile, as it is flushing out bad practices
other potential names for agile were: adaptive, hummingbird, lean (used already), PPP, a bunch of acronyms, did not want a word they would have to wear pink tights and a tutu to explain!
Agile was a coincidence – people following lean in the 1990’s were saying agile is the future, which was good because agile has a meaning in the business world
the most argued item on the manifesto – iteration timeframe, executes terminology
the principles were harder to arrive at
biggest disappointment – everyone wants to be agile but too few people want to do it (when they wrote it they really meant it), the scrumbut
biggest success – uses outside of software (for example Pragmatic Programmer publishing), wanted teams to be able work freely in a way they wanted to work
need a revolution in middle management and need a similar framework for agility
Agile is not the “not-waterfall” – it’s about teams and delivering software
Agile stands as a beacon of hope, for it to disappear would mean the evil empire has won
in software, we still need to ask how do we do a better job?
an Agile process of inspect and adapt is what makes lean companies great
Jim Highsmith particularly called out Jeff Smith, the CEO of Suncorp Business Services as being someone who got promoted from CIO to CEO through the success of Agile
Ainsley started walking the circle to explain the day and how open space works, but frankly it make me feel a little dizzy! She went on to explain that Harrison Owen invented the open space idea as he noticed the real content at conferences was the passionate conversations. The rules of open space are:
whoever shows up are the right people
do not hang on to pre-conceived ideas
it starts when it starts
discussion does not need to be over until it’s over
The law of mobility and responsibility (also known as the law of two feet) is if you are not learning or contributing where you are, go some place where you will. Also, butterflies and bumblebees cross pollinate ideas.
there are two mindsets – offence and defence, testers are defence
job is not to find defects but to prevent defects – build quality in
define quality and what does it mean to us
startups don’t often have the problem – multiple skills required
what is the biggest impediment – are we missing the skill
there is no team of quality anymore – drive quality through the organization
functional testers tend to exploratory test and drive from the UI, technical analysts tend to multiple-skill
you need to have a team focus and a product focus
don’t start with practices but start with a common vision (eg. zero defects)
fear of losing identity if you dissolve roles
understanding the historical roles sometimes helps understands why things are the way they are
need time – Lisa Crispin mentioned that in her company they were going out of business because the system was not good quality, so management were smart to support the initiative
helps if everybody on the team has experienced the entire value chain and needs to understand the value of everybody’s piece of the chain – tendency to optimise the piece of the chain you understand
developers often underestimate the precision of data and scenarios and developers underestimate the difficulty of some requests
personality issues often get in the way
mostly about having the right people – need to let some people go
we assign labels to roles which create barriers – break down on teams but need to break down at the HR level
payroll is also an issue – need to compensate for people taking on more responsibility
need to put queue limits on the testing queue to drive behaviours
pairing with developer if they do not understand the scenarios
some people have the questioning mindset, some have the practical focus – need both to make sure you ship a quality product
mini waterfall problem – long tail feedback loop, change workflow that developer needs to work with tester, avoid lean batching problem
NUnit – Liz Keogh – were using Fitnesse but added another level of complication, wrote a DSL that separates tests to make it easier read, WiPFlash is the automation tool, examples are on the website, can call the fixtures from another testing tool like Fitnesse, capture scenarios on a wiki first to get the best out of the automation tool
SpecFlow – Christian Hassa – similar to Cucumber, scenarios written as steps that are bound to execution, uses Gherkin parser (this is a plus as a number of tools use this)
SpecLog – maps of your product backlog, capture results of collaboration with the business (Jeff Patton’s story maps), data stored in a single file, stories are initially mapped to a feature file but ultimately get linked to a feature tree
SpecRun is under development currently, not bound to SpecFlow or test runner/execution, currently Windows only
Limited Red – Joseph Wilk – uses the probability of failure to run those tests first in Cucumber, can then get failure statistics at a feature level, working on a refactoring tool at the moment
The Smallest Federated Wiki – Ward Cunningham – JSON for data scrubbing, thin columns to display well on mobile, refactoring is the number one edit so allow it to drag and drop refactor, fit for any analytic or outcome-oriented endeavor, sponsored by Nike, under very early development, meant to take spreadsheet data to the next level
separation of concerns – a rule is separate from the action which makes the process more brittle and more difficult to test
rules are a form of requirements and live beyond the building
one process is to extract the rules of a legacy system and then the regression tests – code archaeology
the business does not always know the rules of the system or how they got there – rules get added to the system over time or evolve and documentation is unlikely to get updated
one insurance company had spent $100 million dollars to bring in a business rule engine, returned investment in two years due to being able to be able to look for conflicting rules
put analysis of rules in the hands of developers for way too long
simplest part of business rules is having a glossary
rules engine enables our rules in productions, and use examples to ensure the engine works correctly
testing could look like this – given this data when these rules are applied then I expect this output
you need both rules and examples to test them – you need enough examples for now, need to be different paths, decision points, infliction points rather than different values
examples are not as expressive as arithmetic, but they are not as understandable
lots of rules that we do not think of as business rules because they are baked into the process eg. security access, database schemas
“business logic is not” (Martin Fowler)
you can’t read English as if it were rules, so we need to use examples
the worst systems are the ones that do not have a manual override, humans are usually the best at determining this
lots of business rules change due to jurisdiction
something will always fall to the bottom – rules need to be valued on risk and value – where is the tipping rule
rules are the expression of intent
Mars issue – crashed, six week window too costly to fix
guts to keep it simple – reporting system (Ward Cunningham) – resisted urge to put in a formula system, wait for requests from users, got 6 requests, sold system based on simplicity of the system
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
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 – onedaywithoutshoes.com
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
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.
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.
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.
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.
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 Australia 2011 was held for its third year last week at the Hilton in Sydney. Once again I was honoured to be offered an opportunity to present, be an MC for speaker sessions on both days, moderate a panel discussion and run the end of conference retrospective. The conference attracted 675 attendees and the buzz over the two days indicated to me that the conference was a huge success.
For the second year, it was a great pleasure to be one of the conference advisors. As the conference was brought forward to June, there was only six months to prepare between conferences and lots of suggestions and improvements to implement from previous years. A lot of review, debate and discussion went into putting the program together and ensuing there was a good mix of speakers, variety of topics and sessions for different levels of expertise. More effort was also put into shepherding speakers. A huge thank you needs to go to Rachel Slattery and Zhien-U Teoh from Slattery IT for their commitment to the conference as well as my fellow conference advisors Phil Abernathy, Adam Boas, Keith Dodds, Martin Kearns, Dave Thomas and Nigel Dalton.
The following are my notes from the sessions I attended on the first day.
Keynote: On Beyond Agile – The New Face of Software Engineering
cooperative game – invention, communication and decision making
projects are in a position, look for strategies to move our position, no fixed formula for winning the game (competitors and the economy are some of the enemies), only three moves to invent, communicate and decide
communication – whiteboard discussion provides stickiness over time (can just point back to conversation) as well as proximity
need about 3 minutes of video to enhance the distributed conversation, becomes archived documentation to remember user point of view or architect design decisions
craft – a lot has changed, software development changes every 5-10 years and you need to keep up
people learn skills in 3 stages – shu, ha and ri
work in progress is decisions that have been made but have not been shipped and delivered
like lean we we want multiple deliveries per day – continuous integration has evolved to continuous delivery
in decision making, look for the bottlenecks, the person with the full inbox is the person limiting the work in progress of the whole organisation
knowledge acquisition – real moment of learning often happens at the end when the surprise factor occurs when we deliver work, suggest that at the beginning of a project deliver a knowledge curve ahead of the cost curve (a number of small experiments)
agile says deliver highest level of business value first but projects tend to always deal with the risks first – learn about your business risk (should we build it), social risk (do we have the right people), technical risk (API’s, performance, architecture), cost/schedule risk (gain knowledge about the solidity of the estimates) – you need to decide whether to deliver business values or knock off some of these risks
need to identify the tail to determine whether we deliver business value early or add more features later (Apple are good at this, for example shipping an iPad without 3G initially)
self awareness – the team is self aware when the team can talk about the team and where they are
Keynote – Is Business Ready for Agile
Rob Thomsett delivered this keynote, his slides are available here. He advised that he was going to run his talk in two sprints and check the heart beat halfway
agile is a church of all people – the newbies through to the true believers and a few drooling old people
agile is not new – been going for 40 years
is business ready for agile? – yes and no – every company in the world is ready for agile, they just don’t know it – how do we develop agile into a broader organisational paradigm
we work on a set of models that were developed when the world was relatively stable
the average window of stability for an organisation is about 3 months, change is normal and everything changes
100% of C-level executives believe that project management is too bureaucratic, projects take too long, business cases are poorly developed, transparency is adequate, they expect to be ambushed, steering committees are a waste of time, reports are not accurate
software is not engineering, wrong paradigm, it is a craft
the closest to what we do is not making buildings but making movies
summary: we took the wrong model, flogged it to death so let’s throw it out
agile is a cultural and disruptive journey – first question to ask is are you up for the cultural challenge, for every company that says no there is one that says yes
business approach needs to pass the simple and transparent test – most powerful test to clean up broken processes
go back to work and annoy people by asking people if we can make it simpler
cultural values are openness, honesty, courage, trust and money
the people at the top are the easiest folks to get on board with agile
most people link budgeting to estimating – agile demands we move money around more quickly
sponsors must get dirty – they must be part of the process because they own it
PMO should exist for resourcing, not reporting
Panel – The Changing Role of the CIO
Beverley Head moderated this panel with Jeff Smith from Suncorp, Steve Coles from Allianz, Daniel Oertli from REA Group and John Sullivan from Jetstar.
key is to turn decision making over to employees and leaders need to become coaches and create a great environment
The Corner Office by Adam Bryant gives advice for success – passionate curiosity, battle hardened confidence, team smarts, simplicity, fearlessness
role is to understand where the company is going and deliver things for them to succeed
relax the old techniques like governance that gave a veneer of confidence
need to understand and remove the barriers by becoming an active listener
fundamentals like attract and retain the best have not changed
learn the business in which you operate and realise the definition of leadership has changed (don’t be afraid to higher smarter people than you)
need clarity of purpose, avoid constraint of thought and don’t filter based on your experience
resistance at the frozen layer – middle managers are typically the blockers so need to change the communication structure (for example, using Yammer for communication to give everyone an equal voice)
distributed teams always need a local decision point like an iteration manager
leaders need to eliminate information handlers
offshoring value proposition – you need to decide if your assets are a strategic advantage, do not offshore things that are volatile or if the project is too big to handle yourself (which essentially means you can’t explain it to someone else), offshoring is good because it keeps us on our toes to be competitive and continuously improve
need to look at outsourcing from a productivity point of view and not just a cost point of view (we are not buying pencils)
life long learning for developers – people have to follow their own course, inject talent and different thinking, look back each year and think about what you added to your bag of tricks
most people are capable of learning new skills, that’s the beauty of human beings
what does quality mean – quality is something that is fit for purpose and testable and maintainable, quality is everything
pushing agile into the business – need to agree on one way of working, once you are successful people want to jump on the bandwagon
Agile Architecture & Design
I had the privilege to introduce Neal Ford for this presentation, and his slides are available here. As I had seen many parts of this presentation previously, I did not take many notes as they can be found across other posts on this blog.
don’t pay for technical debt that you may never justify
Key Metrics for an Agile Organisation
It was my pleasure to introduce Craig Langenfeld from Rally Software to deliver this presentation (originally scheduled to be presented by Mark Ortega). The slides are available here.
cumulative flow – look at the top of the line to see what is the scope and how has it changed (total features), then ask if the team limits their work in progress by looking at the time between the boundary of in progress swim lanes, finally look at the lead times and how long it will take to deliver a feature
work in progress limits allow the team to move through work more effectively
lead and cycle time report – allows you to see where your bottlenecks are
stop focussing on the workers and focus on the work product – so rather than lines of code look at the the value delivered
productivity – understand your teams velocity, throughout mapping stories that were completed and carried over
earned value – useful to measure how much value we are delivering (the difference in agile is we are actually delivering the value)
predictability – answering the question of when we will be done – throughput chart can show you if a team is getting more predictable over time, burn up is used to show predictability of meeting scope, release burndown to show meeting a date and demonstrate additional scope being added
use cumulative flow to track the cone of uncertainty
quality – defect trends and counts, most code altered, number of changes, etc…
net promoter score for tracking customer satisfaction and if it is increasing
get customers to vote on what aspects of the product they like and don’t like
for cloud computing track the features that are actually used
Leading by Serving
Simon Bristow delivered this presentation, his slides are available here.
bridge the gap – gaps when making a decision which is the unknowns, bridges the gap to the future by seeing the unseeable
one action at a time
forcing a decision on someone will engender resistance, some you must persuade – need to listen to connect at the grass roots level
withdraw and acceptance – step back from the team to allow them to look after themselves and accept that the team know best as they are the subject matter experts and will get the job done
facilitate community – need to build
lead using art not science – if you turn to science in agile you will turn to process
Soldering Irons, Consumer Devices and Hardware Manufacturing in the world of Agile Software
Dean Netherton and Neil Brydon for DiUS delivered this talk which was one of the highlights of the conference for me. The slides are available here.
DiUS working on a fire danger smart meter and technology for charging electric cars
how do you demonstrate value when haven’t built the device?
had to work around the vendor for the smart meter because they had a traditional process for building the device – aligned project plans around hardware drops and had to simulate the hardware in many cases
used wireframes to drive design but had to spend longer on design to ensure it was right – for example, can’t add a bigger battery later
first drop was an off the shelf component board to kick start the software
second drop was a bare board that was the basic board without the LCD
third drop was the plastics without the screen as the component had not arrived so replaced with paper
challenge on how to articulate stories – had to break stories own technically
used Cucumber to test as there was an embedded USB port on the board – helped embedded engineers assist the Ruby engineers understand how the device worked
did continuous integration by plugging a device into the build server, had an issue about flashing the device when the code changes
hardware engineers slightly change the design with each revision which had affects on software design as well as having hardware for continuous integration
built own hardware prototypes and used local suppliers to cut down lead times (China cheaper but added 6-7 weeks to the lead time)
used mocking to show users the idea ahead of hardware being available
planned for multiple hardware revisions to allow for late decisions
these days you can send a 3D model to a design house and they can pop out a prototype, design exercise ensures that screws line up, etc
no excuses for automated testing, in the past it was not embraced in hardware, can test the integration layer without the need for hardware
no benefit in running tests for the hardware design as you only get a handful of drops
use automated test to ensure buttons and light work, good when you get new hardware and good for checking faults on the production line
had to learn about the hardware stack early on which challenged whether value was being added
firmware development not integrated onto the story wall
technical tasks are OK but really understand what done is
luckily the stakeholders were quite technical
Putting It All Together – Agile Transformation and Development Tooling
Philip Chan from IBM delivered this presentation, his slides are available here. I failed to see a lot of agile in this talk personally.
established teams – communication difficult across timezones but tools make it easy, different tools used in different teams,
IBM agile process – 2 week iterations, 2 day inter sprint break every 4 weeks, develop for first 6 days followed by 2.5 days for bug fixing, do acceptance testing for first 6 days and 2.5 days of exploratory testing, showcase on day 9
test management very waterfall for audit purposes
using automated tests and continuous integration to assist global team optimise processes
continuous integration – everyone in the team integrates with the mainline at least once a day
continuous delivery is taking the same approach as continuous integration and apply it to the last mile – decision to deploy should be business only with no technical barriers
continuous deployment is continually delivering on a regular basis – continuous delivery enables this if you want it
rare to find a company that is pulling in the same direction, so you need to automate in pockets and add manual checkpoints and then you can look for ways to automate them
risks – need to bring pain forward, which was the tenet of XP, not doing it is much more risky, there is pain and effort to setup, you need to look for a leverage point in your production systems to justify
if you do something rarely you don’t get practice, by doing it more often you improve which actually results in a process that is more auditable and gives you more confidence
is a good approach to shorten feedback loops, also allows you to give confidence to the business on delivery timelines
packaged software makes continuous delivery hard, important to look at the automation of the configuration as well as automated tests, looking for fast feedback to give confidence in delivery
need to push software vendors to make things more deliverable (this was a rant by Martin Fowler, that I tend to agree with)
make database changes with the same fundamentals – break them down into small changes and combine schema changes with the data migration and string them together into a package, tools have got more specific like dbdeploy and Liquibase support this and Ruby on Rails just supports this out of the box
DBA’s are the final frontier because they like to fiddle with scripts, need to bring them in or deal with smaller changes
testers tied to manual processing – need to separate the low and high value testing work, fear that they will be replaced by a small shell script, will make their job vastly easier, need to get buy in by demonstration
difficulty is always the human element – testers are moved from the backend to the front end of the process, specification by example at the front now, need to look at incentives and make them common between developers and testers
key is a business decision of when to delay so you can deal with business change, training, etc…
people are now used to the fact that websites or apps on their phones are continuously changing
gives the option to deploy to different types of users when they need it
Go was built with continuous delivery in mind, version control systems are critical because everything needs to be in there, automated testing tools are also critical, continuous integration servers can help if they have an extra build pipelines
Puppet and Chef both allow you to script your environments
need to place people in teams who believe things are possible
Other Stuff
At the end of a very long day, it was good to network with attendees at the ThoughtWorks open office.
On behalf of the Agile Academy, Tony Ponton and I presented First Steps in Agile to a small but enthusiastic class. The course covers introductory material around the values, principles, practices and agile approach.
Alistair Cockburn – Introduction to Advanced Agile Development
I had the pleasure of sitting in the back for Alistair Cockburn‘s workshop, with Tony Ponton and Martin Kearns. Whilst I had seen some of this content in Alistair’s Agile 2009 keynote, Tony and Martin had been lucky enough to sit in Alistair’s 3 day class earlier in the year.
Alistair does not use slides but rather a one page laminated handout. My comment to Alistair at the end of the workshop was “Second time hearing it, learnt twice as much”, so here are my notes from this time around.
efficiency is short term horizon versus effectiveness which is long term horizon
why is agile less efficient – agile people are looney because we keep changing everything over and over and over again (requirements, design, test) plus the skills needed to be around for the entire project
why is agile more efficient – we make things more tacit which means teams work faster (not writing things down)
shu, ha, ri (practices, theory, self awareness) – move up and down the scales
The Oath of Non-Allegiance – “I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.” – basically, I will not reject an idea just because of it’s heritage
shu – when people encounter a problem, they want a technique (shoe box)
ha – when you start collecting techniques
ri – when you start making things up, merging ideas together
there is often combat between the shu and the ri on projects
craft – skills in a medium and life long learning – many 10-15 year programmers don’t see themselves in a craft, your medium is your programming language and for project managers the medium is people
cooperative game – people issues matter, software development is the combination of invention, communication and decision making, agile has brought team collaboration the top level
right level of documentation – might be more if people are joining and leaving the team regularly but might be less if the team is stable and there is little movement
most efficient documentation is video taping two people at a whiteboard, faster than typing and easy to create – users to describe their problem, etc…
design = distributed cognition – need to get everybody to understand the theory of how the whole works and a theory of a solution and we need to find the answer between the two that everybody can understand
keep an open mind
each project should keep the next project in mind
a little out of balance is OK
the length of a programming episode is 1 hour – separate slices to demo within a sprint – (see the Carparccio exercise)
tip off for a bottleneck – “we don’t have time for…” or “spare capacity to develop…”
learn early in the project to learn and reduce risk, then develop for value once risks are down, then deliver early or delay for scope / quality
Zynga put in features that don’t work and count the clicks to determine whether to build it and other companies get users to pay a Paypal account and if they get enough money they will build the feature
every month / iteration / delivery – reflection of what we keep and what we try to do next month (two columns) – what we did wrong does not help me
My presentation from Agile Australia 2011 called “The Speed to Cool – Valuing Testing & Quality in Agile Teams” is available on SlideShare.
Ensuring that the approach to testing and quality is understood and appropriately valued in an Agile world can be a struggle for many organisations, especially when resources are limited and our customers are expecting business value in a timely manner. In this session Craig Smith will define what quality means, share a number of tools for measuring it as well as discussing approaches to improving the skills, empowerment and role of testing in the organisation and share why testing is the coolest role on the team and why it is everyone’s responsibility.
Some of the comments on Twitter included:
@AgileAcademy: Good luck today with your presentation at 11.30am on The Speed to Cool: Valuing testing and quality in Agile teams @smithcdau#agileaus
@vivierose: Everyone likes to be seen as valuing quality, just like they love kittens, but it’s the 1st thing to be dumped #agileaus@smithcdau
@stephlouisesays: #agileaus loving @smithcdau challenging how well we apply the manifesto to testing. Card wall stages look remarkably like a waterfall… Hmm
Day 2 of the YOW! Australia software development conference in Brisbane, the following are my notes from the sessions that I attended.
Keynote: Exploring NoSQL
Erik Meijer delivered this keynote, which essentially proved that relational databases and NoSQL are mathematical opposites. The slides are available here.
“NoSQL took away the relational model and gave nothing back” – Benjamin Black
SQL is complicated and not very efficient
principle of compositionality
SQL and NoSql are opposites mathematically
Leveraging Internet Technologies to Build a New Breed of Software Development Tools
Martin Nally from IBM delivered this talk on development tools and RDF, his slides are available here.
78% of people cite delivery pressure as to why they don’t use ALM
vendors believe their tool is the centre of the universe – if that is the case you need to know the universe
AD/Cycle tried a central repository model in 1990 – did not work, but most vendors still trying to this
currently we try to use the integrated model
third option is to use the world wide web and linked data (Tim Berners Lee) – give everything an URI, use HTTP URI so people can look them up, provide useful information on lookup (RDF), include links to other URIs – this is just REST!
“tools are just a prison for data”
we still build tools like we built applications in the 50’s – need all the data
RDF – universal data representation for the web, SPARQL is the RDF query language – XML looks awful for RDF, Ntuples is much easier
decided that UX and development went separate ways and proceeded in two different stream
incrementally develop in a series of internal drops
3 stages of UX evolution – idea storming (consider all options and dismiss them), prototyping (let designers choose their tools) and user testing (ease of use, makes sense, sketchy UI)
develop the UI after interaction has been defined, so start by developing the plumbing
designers and developers should use their own tools but talk a common language (markup)
PARC(T) model – from The Modern Firm by John Roberts – People, Architecture, Routines, Culture and Technology
code wars
point kaizen (optimize points in the process)
flow kaizen (optimize the entire flow)
theory of constraints – keep working on the one problem that is causing you the most pain
systems management.theory helps bridge the gap from agile
kaizen vs kaikaku – kaizen only gets you so far because you see a slide, sometimes you need to introduce massive change
you can inspire people but they need to bring their own motivation
transforming REA – great people, cross functional teams, visual controls, agile and lean concepts, engineering practices, DevOps and hearts and minds
build a compelling vision (where do we want to go and follow)
decentralize responsibility and let go of control (people aren’t grasping in the way we expected, developers don’t grasp the business, take time to go out on sales calls, barriers they think are there are not really there)
work on the culture and the system
build a great environment (productivity gain has been huge)
look for trouble makers and throw them into teams with no trouble (wisdom of the crowd)
take risks, learn and move on
Row Together, Row in the Right Direction, Row Faster: Improving alignment and throughput in software development
Jason Yip delivered this talk, the slides are available here.
the best programmers are 10 times better than average which is 10 times better than worse
set the best performers as the standard (not the second worst performer) , teams only as strong as weakest link
need explicit time for performance and practice
lower threshold for incidents, raise threshold for incident response (fix the problem)
Day 4 at Agile 2011 brought a full day sessions full day of sessions followed by the conference dinner. For the first session I used the law of two feet and landed in three different sessions.
Craig Smith 
You must be logged in to post a comment.