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
And so much time was spent on referring to this book or that book that we just had to link what books we unwittingly covered in what we like to call Tony’s Oprah Winfrey Bookclub!
Chasing the Rabbit or now known as The High Velocity Edge by Steven Spears; recommended by Tony as a great Lean book.
Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larson; there might be a reason why this wasn’t discussed, but Renee did read it recently; it was okay but potentially an overrated book.
Quotes:
“Some tribes are stuck. They embrace the status quo and…
The last day of the Agile 2011 Salt Lake City conference where Craig talks about Kevlin Henney’s presentation of Functionality being an asset and code is a liability and Linda Rising’s presentation of The Agile mindset.
Craig spent the day milling around a number of presentations today and talks about how technologies link together, delighting customers, visualisations, ATTD for start-ups, Jeff Patton’s User Story Mapping and flirting with your customer.
Craig Smith is fighting the hard war on Agile Software Development Frameworks and despite jet lag worked hard to bring us his first of a series of daily takes from the 2011 Agile Conference at Salt Lake City.
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
Craig, Tony and Renee spent quite a bit of time today looking at stories and particularly some of the odd terminology that surrounds them.:
Craig Smith 
You must be logged in to post a comment.