The Secrets to Leading Virtual or Dispersed Agile Teams

AgileBrisbaneAt the April 2016 Agile Brisbane meetup, we were lucky to have Korrine Jones present on Leading Virtual Teams. Korrine is the author of “Virtual Team Reality: The Secrets to Leading Successful Virtual Teams and Remote Workers“.

Check out her slides for the full summary of her talk, but here are my notes from the talk:

  • distance does not make a huge difference once you are not co-located – whether a floor away or across the world
  • challenges – time zones, culture, accountability, multiple competing stakeholders, latency in communication, availability and willingness, no body language

Korrine Korr

  • Albert Mehrabian principle – to interpret meaning it comes from 7% words, 38% tome and 55% non verbals – which explains why we have so much breakdown in virtual communication, on the phone the breakdown is 8% words and 82% tone
  • success factors – top notch leadership, clear goals, periodic face to face, frequent communications, attention to cultural differences, maximised communication quality
  • a virtual leader needs to amp up the skillet of a good leader – communication, listening, open dialogue, goals, team dynamics, culturally sensitive, results focussed, handle conflict
  • need to develop a shared team vision
  • develop a social contract – ask what are the values, then to get around understand and cultural differences ask them to explain what that will look like
  • fave to face inductions for new starters has a better chance for success
  • high clarity processes, the team performance grows as the dispersion grows
  • select people who are self starters, tech savvy, autonomous, actively reach out to collaborate
  • manage by outcomes not activity (as you can’t see them) – so need to agree the objectives, collectively make a plan, collectively monitor performance
  • GROW coaching model works well for remote workers, ask them what the goal is, what’s happening now, where are you at, what could you do, what do you need from me
  • build one on one relationships – regular deliberate contact, focus on those most remote, have purely social conversations to build connection
  • swift trust – trust that builds easily, SES has this because they know others have training, but one breakdown in conversation this breaks down
  • need to move from swift trust to real trust – do you know the needs and expectations that you team needs from you and you need from them, these need to me be met for trust, it’s a simple conversation we often don’t have, you may need to lead the conversation for others to reciprocate
  • virtual meeting – need to amp up how you chair, what are the protocols (eg mute when not speaking, raise hands, etc)
  • virtual celebrations – have lunch or celebrations at each end
  • have a ritual or something at the start of a call – a fun example is 2 truths and a lie or a list of words that can be snuck into a conversation
  • consider the richness of your tools

Korrine alluded to these YouTube videos on virtual meetings, worth a watch!

 

Episode 101: The Lean Mindset with Mary and Tom Poppendieck

The Agile Revolution Podcast

craig-poppendieckCraig catches up with two luminaries in the Agile and Lean space, Mary and Tom Poppendieck at YOW! Conference to talk about agile, lean, rapid feedback, culture and leadership. The discussion points include:

  • Making the link between lean and software development and discovering that waterfall makes no sense
  • The origins of the first book: Lean Software Development: An Agile Toolkit
  • Agile is not lean in software development, Agile is lean in a delivery organisation
  • How long does it take you to put a single line of code into Production?
  • The manifestation of lean really kicked off in 2010 with both the rise of DevOps and the Lean Startup
  • Delivery organisations versus engineering organisations and the journey of Agile
  • Agile has not well addressed delivering the right stuff, solving the right problem and the architecture of rapid deployment
  • Only two goals at ING: Deliver every two weeks and don’t crash production, resulted…

View original post 128 more words

Michael Hamman, Lyssa Adkins and Michael Spayd on Integral Agile and Coaching for Teams, Management and the Enterprise

InfoQMichael Hamman, Lyssa Adkins and Michael Spayd of the Agile Coaching Institute talk about Integral Agile and the personas of Agile Coach, Enterprise Agile Coach and Organisational Leader.

lyssa2Source: http://www.infoq.com/interviews/agile2015-hamman-adkins-spayd

Derek Sivers on TED

TEDWatched a couple of short, unrelated videos on TED today from entrepreneur Derek Sivers.

When starting a movement, it takes a leader but the first follower is actually an underestimated form of leadership in itself. … The first follower is what transforms a lone nut into a leader! There job is to make it OK for others to join and to make it more safe.

Whatever brilliant ideas you may have or hear, the opposite may also be true. He gives the example of naming streets in Western culture, but blocks in Japan and how eastern doctors get paid for keeping you healthy, not treating you when you are sick.

Keep your goals to yourself because telling someone your goal makes it less likely to happen.

Agile 2012 Day 2 Review

Agile 2012Day 2 of the Agile 2012 conference in Dallas, here are my notes.

Keynote: Scaling Up Excellence. Mindsets, Decisions and Principles

This keynote was delivered by Bob Sutton, author of a number of business books including “Good Boss, Bad Boss” and “The No Asshole Rule“. A similar presentation to the one he delivered is available here.

From Agile 2012
  • organisations have centres of excellence – how do you spread it from the few to the many without screwing it up? (examples – Hendrick Motorsports growing from 2 to 4 teams, McDonalds opening 1,460 stores in China)
  • shared mindset (what people should and should not do) is crucial to scaling up – Apple has a secrecy mindset, Amazon has an openness mindset, so there is no one right way
  • a mindset is required to be successful at Agile – going to a talk or reading a book is not enough, you need to grind out the message and do the same thing day after day and live by it (Facebook – employee on boarding is a six week bootcamp where they work on 12-13 short projects, focus is to inject people into the mindset and determine their best fit at the organisation)
  • the never ending danger is that things might go bad (Onward Memo by Howard Schultz – growth of Starbucks from 1,000 to 13,000 stores, in the rush to get a huge footprint, the mindset got watered down – got excited by growth and left the excellence behind)

Choice Point 1 – More vs Better

  • strategic tradeoff
  • voltage loss – things get lost in the translation, sometimes this is worth it because it is half as good as the best but twice as good as it is now
  • learning curve problem – takes people a while to get good when spreading knowledge from the few to the many
  • overload problem – burden of the management team in trying to maintain momentum

Choice Point 2 – Alone vs With Others

  • collaborate with competitors (Glad Press ‘N’ Seal), open source is one extreme, do it alone is the other (everybody at Pixar is an employee, nothing is outsourced

Choice Point 3 – Catholicism vs Buddhism (Replication vs Localisation)

  • roll out to the masses or a central set of beliefs
  • cranking out clones – works in manufacturing like Intel plants, Sees Candy and In-N-Out Burger either work in a market or not (pull out if not)
  • replication trap problem – Home Depot is a DIY model and when they rolled it out in China it did not work in their culture
  • localised solution – Buddhist approach to tweak just as much as needed to make it work

Scaling Principles

  • link hot causes to cool solutions – fire up contagious emotions first, humans are irrational, to motivate people get them emotionally cranked up (but the danger is that they get angry) so need to have a solution to cool their energy (watermelon offensive at Stanford for bike safety involved smashed watermelons and subsidized helmets or the first all-hands meeting at Apple after Steve Job’s return where the share price was not good so Jobs declared war on Dell and charged up people to make Apple great or get out)
  • live a mindset, just don’t talk about it – do actions that are consistent with the direction you want them to go, what we tell them doesn’t matter it is what they do that counts
  • when in doubt, cut it out – reduce cognitive load but deal with necessary complexity (A.G. Lafley keep it “Sesame Street simple”, Baba Shiv experiments on cognitive load for 2 vs 7 digit numbers), go simpler when trying to sell a message
    • when systems get larger and more complex, you need to deal with the complexity – Ben Horowitz “give ground grudgingly”, add people and processes only when things start to break down
    • Hackman’s rule for teams – over 6 people problems arise, more than 10 you are really in trouble, optimum is 4-6 people, Navy Seals and fire teams have 4-5 people, any more is more complicated
    • Dunbar’s number is 150 (100 to 230) – the cognitive number of relationships we can manage, pirate ships only have about 100 pirates per ship before dividing, Twitter average is about 100-200 followers
    • as the team gets bigger you spend more time on the dynamics and less time doing the job
  • little things pack a big wallop – subtle cues mobilise mindsets – design things that people barely notice but have a huge impact on their behaviour (background music, language, smells and sounds affect people’s behaviours)
    • Kathleen Vohs money research – people are less likely to ask for help or give help, will work alone when money is the object – leads to selfishness and self sufficiency
    • think about the little cues you are sending
  • connect people and cascade excellence – get one group to mentor the next to spread the excellence, grow your own replacement to get a promotion (Zynga), make your initial group diverse because more variation will give you a bigger impact
  • the mindset is the steering wheel and incentives are the juice – money is an incentive but so are pride and shame, how can I embarrass them or how can I make them proud (using mimes to mimic jaywalkers, Ben Horowitz fines people $10 a minute they are late for a meeting – it is not the money that motivates them it is the embarrassment, gets them to pay him on the spot!)
  • don’t put up with destructive beliefs and behaviours – bad is stronger than good, bad behaviours are ingrained more deeply, to spread excellence you need to stop the behaviours, bad behaviours are 5x worse than the good, destructive team members that can’t be reformed can bring down performance by 30% to 40% because you spend more time dealing with them rather than the work (Barry Feld of Cost Plus World Market would look for two things when visiting a store – greeting me and the customers and are the bathrooms clean)

Traps

  • don’t mistake swarming for scaling – raising awareness is not enough
  • too fast, too far – when people say they want to scale quick and fast, they are looking for the easy way (you are fighting a ground war not an air war)

When scaling you need to be master of addition and subtraction. – everytime you add something good, you need to remove unnecessary and bad things to make way for the good.

I also wrote an article on this session for InfoQ.

Why Agile Needs More Cowboys

Mike Griffiths presented this talk, his slides are available here.

From Agile 2012
  • do you ever see cowboys looking after cows?
  • real cowboys protect the herd, select the lead, direct into natural flows
  • agile is humanistic rather than mechanistic, so is leadership – manage property and lead people
  • “Leadership is the capacity to translate vision into reality” (Warren Bennis)
  • levels of maturity (Stephen Covey) – dependent -> independent -> interdependent
  • leadership is the next step beyond management – to a soft skills focus
  • productivity – undermining / resistance -> passive compliance -> active participation -> committed dedication -> passive innovation – move up the scale with good leadership
  • model desired behaviour – same attributes of a good leader are modeled over many years and in different countries – honest (will not knowingly follow someone who is dishonest), forward looking (describe the future state), competent (don’t want to be embarrassed by our leader), inspiring (The Leadership Challenge), a leader needs to shield the team, remove impediments, carry food and water and re-communicate the vision
  • communicate a vision – like driving in fog, without clear vision you need to slow down, clear direction allows focussed effort and speed, Jim Highsmith’s kick off meeting vision exercise, reinforce the vision frequently
  • create a learning and sharing environment – “if you have two hands to work with and you use one to cover your butt, you only have on hand left to work with”, set an example and admit mistakes and share information, ask questions of your team, make it OK to discuss the bad stuff
  • share information / power – agile tools allow move from micro management to navigation and communication
  • fostering functional accountability – accept that conflict is good, Patrick Lencioni on The 5 Dysfunctions of a Team
  • importance of the team – COCOMO Estimation model (Barry Boehm) shows that people factors has a multiplication factor of 33 (there is a 10x difference on good people over good process)
  • challenging the status quo – retrospective, “areas for improvement” works better in some cultures over “what didn’t work well”, retrospective action wheel, gathering lessons learned is one of the most frequently dropped agile practices
  • innovation and learning – if people are trying hard, then mistakes don’t really matter, Toyota collects lots of ideas with small incentives rather than one big idea
  • encouraging each other – treat people as volunteers, paying people just incentivises people to show up but volunteers are passionate, say thank you and why you are thanking them and what the benefit was, celebrate interim goals frequently, at the end is too little too late
  • shared leadership – aiming for teams of competent leaders (“Project Leadership” by Jeffrey Pinto)

I also interviewed Mike Griffiths for InfoQ.

Leading Conflict: A Systems Intelligence Approach to Conflict Facilitation for Leaders

This workshop presented by Michael Spayd and Lyssa Adkins was one of the highlights of the conference for me. The key takeaway for me was that “everyone is right… partially!” The slides are available here.

From Agile 2012

The workshop started with a discussion on the conflict we see on teams and then about why we came to the session and what we had hoped to get out of it.

  • systems oriented leadership – structured, holistic, organic, complex, end to end – move from the work level to a birds eye view
  • relationship systems intelligence – we are all in relationships – personal, work, departments
  • the human system is not in alignment with what agile does, leadership begins inside
  • see conflict through the right view – the right view leads to the right action, everyone is right partially, self organisation happens when all perspectives are represented, conflict is something trying to change in a system and not a problem to be managed

We then had a discussion around what is the benefit of the right view, is it difficult?

  • what is the difference between finding someone wrong as to finding someone right – go and hunt out why they are right
  • container – not necessarily physical but made up of behaviours, norms and culture of the team and environment

We then did an informal constellation exercise – 20 people in a circle, put the subject on a piece of paper in the middle, make a statement if it is true stand close, if not true stand away then ask those in the constellation what it means to you, need to talk from experience not what you think, remember people are right partially (take a soft focus). It is called a constellation because it looks like a star in the sky, speak from your experience, only people who wish to speak should

From Agile 2012
  • container – culture of the team, want to raise level of positivity and decrease level of negativity and toxicity, educate team about conflict and team agreement about digging into it
  • positivity and team performance – continue to abdicate your position is bad, needs to be balanced with inquiry – “not sure I agree with you, but tell me more”
  • all teams have an emotional bank account – positive interactions are a deposit and negative interactions are withdrawals, what is positive for your team and what is “flipping the asshole bit”
  • build the container – positivity vs productivity
                Happy camp     |    Insanely great
Productivity    ---------------+-------------------
                Prison camp    |    Sweat shop         
                           Positivity
  • emotional withdrawals – blaming, defensiveness, stonewalling, contempt, excessive advocacy – contempt is most prevalent on software projects
  • emotional deposits – appreciations (noticing people doing little things, in front of the group), acknowledgements, more inquiry and less advocacy
  • never praise people for the work they do, but for who they are, turn up acknowledgements and turn down appreciations
  • appreciative inquiry – look at the strengths of teams

We then had a discussion around our teams positive /negative ratio

  • dealing with cultural conflict – inquiry openness, use my land your land ” in my land we…, what happens in your land?”
  • teams move around the quadrants – prison camp is not sustainable, happy camp and sweat shop are intolerant
  • conflict protocols – team needs to come to consensus, leader needs to take a facilitator / coach role – what is the environment and behaviour we want when we are in conflict, everybody’s job is to call out the protocols when needed, not enforce them
  • be a facilitator – more helpful than resolving it, keep reviewing the right view beliefs (fake it till you make it), understand your triggers
  • process the conflict – reframe the conflict” “I wonder what this conflict is trying to tell us”
  • don’t want debate or vote, a prelude to a discussion to find out what’s true
  • we get triggered by people who are like us who exhibit behaviours we don’t like
  • Getting to Yes – Roger Fisher
  • to hear from silent others, ask “lets hear from those who have not not spoken” and then be silent

I was lucky enough to interview Michael and Lyssa with Shane Hastie for InfoQ.

The Product Owner Role is a Stupid Idea: Improving How We Handle Customer Requests

Jeff Patton is always entertaining, and I was not disappointed with this session. I would hope that his slides get published at some stage.

From Agile 2012

He kicked off the session with a live poll by getting the audience to answer the question “what goes wrong with product ownership” and then got everyone to move around the room based on experience, how well the product owner works (they don’t correlate!), internal versus external product development and the ability to change products

  • why is there a difference between developers and customers?
  • single product owners don’t work – whole teams own products
  • processes aren’t designed for success (including Agile ones)
  • safety isn’t success – Nordstromare a big successful company so they have lots of rigour around their process, nothing innovative gets through the net, so they built an innovation lab
    • waterfall model – step after step models have no feedback, Royce was trying to explain why it was a bad idea, experts have been trying to tell us why this is bad since the 70’s, traditional development models are safe
    • agile is the new waterfall – product owner creates stuff and gives it to someone else – someone to blame like the preceding process in waterfall
  • velocity isn’t value – being great at delivering software using agile then you should realise that it doesn’t matter, if we build more shit we just have more shit, we are not here to build software we are here to change the world, everything that happens (outcome) is after delivery, so need to maximize this, difficult to measure
  • underpants gnomes – a meme for something people are building but have no idea why
  • to get value you must form a hypothesis on how you’ll get it – this is the first shift companies need to make – how will we measure the output
  • one balanced team not client vendor – if we want to fail we can probably fail cheaper abroad
  • ideal product should be valuable, usable and feasible, product manager understands the value, UX or BA understands the usable, lead engineer understands the feasible, this is a balanced team – how should we build it, will they use it and how much will it cost
  • working as a team of comakers, we need to do a lot of mind reading, visibility is not good enough, shared understanding is what we are striving for
  • discovery complements delivery, morale suffers when we just build stuff, the thrill is seeing how well it works and debating the results and planning the next approach
  • story maps describe outcomes that we are shooting for
  • personas – don’t necessarily need to be accurate documentation but facilitate shared understanding
  • need face time with real people to understand, go watch people work to learn, then build models to map what you learnt (experience or journey map), when users explain a problem that should trigger an idea, share product story or product as part of a regular internal tradeshow
  • we need to understand the problems and find solutions to get us there, MVP (minimal viable product) should be the least we can build to solve a particular problem,
  • a newer version of MVP is lean startups (build -> measure -> learn) MVPe, smallest viable experiment so that we can learn and eventually earn
  • ready for release board – for each card, an explicit measure step and metrics, then before it leaves the board they need to learn
  • Nordstrom Innovation Lab learning loop – Replace the Mirrors – look for the number of learning loops, no idea on their velocity but we know how much they learned, just budget for learning – “life is better here, even though we fail most of the time”
  • you fail most of the time at predicting outcomes and getting value (Marty Cagan – Inspired)
  • making good product decisions is hard, focus on how fast we learn and how fast we get things out there
  • don’t focus on velocity and worry about who’s fault it is, focus on the things that matter

To succeed:

  • adjust your head – get out of the old client vendor model, be less like a waiter and more like a doctor and solve problems
  • take on the persona of a music producer – listen to bad music and help make others ideas better
  • be the film director – focus on the talent of the people you are working with, give direction and passion without stealing ownership

Industry Analyst Panel Discussion

I sat in the first 40 or so minutes of this discussion. Unfortunately, the room was so packed and the panel was not elevated so it was very hard to determine who was saying what. The panelists were Tom Grant from ForresterThomas Murphy from GartnerMelinda Ballou from IDC and Christopher Rommel from VDC.

  • should we stop focussing on agile adoption?
    • disagree – fewer people to execute, focus on importance, deliver benefits quickly, tackle issues like mobile and embedded
    • agree – not about how many people are doing this or certifications, there are plenty of problems to solve, a foregone conclusion, let’s tackle the bigger issues, adoption is superficial metric, plenty of challenges beyond pure software development
  • can you define ALM?
    • no agreed definition, lean concept of flow, includes the tools and processes
    • typically think about standard phases but the end to end lifestyle doesn’t work, now need to look at DevOps and cloud now, more complicated to deploy now
    • ALM tools are a misnomer, output of SDLC, fundamental issues with tools currently, we do not develop and done any more, need to start thinking about products and products have lifecycles
    • going forward will be more about traceability of past development and operations
    • worst thing is the name
  • what should we call ALM instead?
    • Application Lifestyle Context
    • Gartner are talking about this internally
    • nirvana…, once the new taxonomy is decided it will be antiquated, we are here to improve!
    • dynamic end to end process, software lasts decades longer than we expect it too, needs to sustain life
    • ripple effects of agile disrupts it
  • Gartner’s prediction of 80% of software development teams doing agile by 2012, where are we?
    • at least 80% of all IT organisations have some agile and 20% of large organisations, on everyone’s mind, businesses are talking about it, will probably still be another 10 years because big change takes that long
    • estimate that 40% of organisations are using agile, has blown past all the other methodologies, businesses realised recently that they’re not innovating
  • are we seeing issues with organisations part doing agile and part traditional?
    • often the only way organisations are initially successful, different processes (eg. software and embedded), needs to rolled out staggered and incremental
    • fair adoption in development teams, but now what does it mean to be a tester, lots of centres of excellence still exist, Facebook deploying every 25 mins scares the heck out of most traditional organisations, companies need to get to the right fit
    • majority of Agile teams are not purely Agile, use water-scrum-fall, slimming down requirements and deployments is not sprinting, Facebook analogy does not fly with corporate clients
    • need to begin where people are, approach what is the best for the organisation and adjust for the context
  • how do you measure effectiveness of Agile methods and compare them?
    • prefer not to speak about methods but rather patterns and practices, compare using customer satisfation, ROI long term for the organisation, organisations still like function points delivered because it is easier to count
    • one of the biggest pluses is on quality and that is subjective and hard to measure, metrics that can point like customer satisfaction, rework and defect counts, time to market also better, it is often a leap of faith
    • velocity interest is going down in industry, but many in the executive suite only think about velocity, a loaded word
    • don’t know soft value if you don’t baseline, now we just fix metrics inline and not all defects and features are equal, need to measure qualitative benefits to the business, will see more as metrics around Agile evolve
    • need to pull testing and quality in all the way through, drive better quality and user experiences
  • describe how you evaluate the tooling landscape?
    •  most observations come from end users, tools aren’t the key most important thing, want to understand where the market is going and what is the right fit
    • biggest differentiator is picking the right tool for the job and the organisation
    • there are tools that enhance Agile that were not built for Agile, and there are specialised tools for Agile, vendors do put thought into who they are targeting so you need to listen, we don’t live in a world where everybody gets their tools from a single place

After Dark

A huge thanks to my friends at Atlassian and Opower who allowed me to tag along to an awesome Tex-Mex joint in Grapevine called Uncle Julios.

From Agile 2012

Podcast

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

Lean Software Development Workshop with Mary & Tom Poppendieck

YOW! 2010I was cleaning up some old files, and came across my notes from a workshop I attended with Mary and Tom Poppendieck entitled Lean Software Development – Leaders Workshop at the YOW! 2010 Australia Developer Conference in Brisbane. Obviously the slides and commentary have a wealth of information, but here are some of the key takeaways I had.

  • stop doing stuff that does not deliver value, not laying people off
  • spend time doing the right stuff, not the wrong stuff
  • think systems, not software – Southwest think employees, customers and then shareholders
  • optimise the whole system (software is just a layer) – Amazon is structured around it services (2 pizza teams of 8-10 people)
  • a separate testing team is silly – just handoff / afterthought, need to build quality into your product
  • need to understand value before you deliver value – understand what your customers value, not what they want and build the right thing before building the thing right
  • setting up a new product is a set of learning loops
  • watch for what is making people uncomfortable
  • understand your customers not by bringing an idea but by taking the team to understand the problem
  • there is always demand in a service company – fix issues as fast as possible, but that is not the game
  • consumability – how much effort does the customer need to go through to get value?
  • customers decide value… and therefore decide waste
  • measure productivity on value delivered, not features
  • work in progress is waste – customers are not interested in your long list of things to do
  • good Agile teams have a low number of defects
  • map end-to-end flow to find the biggest opportunity in your end-to-end process
  • 40-90% of the cost is maintenance not delivery, the cost of quality is way higher than the cost of building quality in, don’t put defects on a list (track them, fix them immediately), root cause every escaped defect, determine why every one happened
  • problem with readable specifications is that the text is not refactorable – any text page will have hundreds of ambiguities
  • every organisation that calls itself professional should be doing TDD
  • legacy code is code without unit tests, use Martin Fowler’s strangler pattern or the Mikado method to refactor
  • expertise takes 10 years / 10,000 hours of deliberate practice, need a teacher to challenge, feedback and dedication (The Road to Excellence)
  • marketing leader – for a successful product you should be able to name this person
  • technical leader – keep two top engineers free to roam around and give guidance
  • Empire State Building – on time and under budget, had to manage the flow of materials not tasks, had two alternating mills to keep up schedule and remove failure point
  • people who have dome something before should know how to deliver within the constraints
  • when managing an organisation you need to manage the capacity, you need to have a stable flow
  • kanban – reduce work in progress to expose problems (don’t crash your boat on the first day, keep your limits high then lower your limits and remove your problems one at a time
  • kanban board – every column is handover to the next column, the next column (downstream process) gets to define done
  • 5 why’s – the cause of the cause of the cause of the cause…, The Team Handbook has good process improvement practices, as do the Six Sigma tools
  • delivering value – read Competitive Engineering by Tom Glib and Value Driven Development
  • product-centric development – 54% of Fortune 500 companies are heading in this direction
Here is a picture of an exercise we did to map the cycle time of a particular company (it highlighted some of the issues they are having around approvals).
From Miscellaneous

Finally, a huge thank you to Nick Muldoon from Atlassian who helped me out with a space on this course. Also to one of my colleagues who reminded me that we should ask forgiveness not permission when I was dealing with some competing priorities!

Episode 15: The Perfect World of Agile

The Agile Revolution Podcast

In My Perfect WorldThe usual crew get together again:

Quotes

“Don’t mix dev ops with dev oops!”

“99% of we bapp bugs are caused by 1% of browser types #occupyinternetexplorer”

“Gartner’s analysts are predicting that by 2012 that Agile development methods will be used in…

View original post 64 more words

Agile 2011 Day 4 Review

Agile 2011Day 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.

From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011

Creating Customer Delight

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.

From Agile 2011
  • move from output to outcome
  • customer must be surprised and delighted
  • move from implicit goal to explicit goal
  • custom delight is the new dimension of done
  • product owner adds contingent valu
  • bottom line is whole organization, not just the team
  • customer delight is measured eg. net promoter score
  • 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.

From Agile 2011
    • visualise your work  in progress (WIP) by putting every project in progress up on the wall, also visualise your demand
From Agile 2011
From Agile 2011
From Agile 2011
    • model your application assets – you will be surprised what you will find – link them, then order them by business value
From Agile 2011
    • create a radiator wall for each one of your assets – understand technical debt, print out each of your defects, be ambarrased!
From Agile 2011
From Agile 2011
    • visualise your org chart – particularly where your skills are, then rank them by apprentice, journeyman, master – then you can score your aptitude
From Agile 2011
  • 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
From Agile 2011
    • 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
From Agile 2011
  • make roadblocks visible – you will get more respect from you people – put one up for every person who has the title manager in your organization
  • leadership team to do retrospectives every two weeks – take people out of their element, makes them more likely to talk
  • continuous improvement – force it by shutting down email, block out meeting rooms
  • you would save money on coaches if you got people to read books, free ice cream by reading a chapter in a room and talking about it in an hour
  • pair management – pair on everything to get better, pair in public which will show developers pairing is ok
  • change name of PMO to MSO (manifesto support office), make them in charge of ensuring the visual radiators are up to date
  • dashboards are costly and evil – they are not the truth, data is mostly inaccurate
  • speak in story cards – create a wall to get answers to things you want to know

Acceptance testing in the land of the startup

Joseph Wilk presented this session, his slides are available here.

From Agile 2011
  • 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
  • Crazy Egg – monitor what users are actually using
  • use WIP to keep testing under control
  • 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.

From Agile 2011
  • user stories are the simplest idea in the world, but like any simple idea they all get screwed up
  • it’s easy to lose the plot when you have a lot of stories
  • story mapping – tells the whole story of your product and still gets down to the iteration level
  • you already know this stuff!
  • “sharpie markers smell like ideas!”
So…
    • dump ideas onto stickies, on your own – they should almost always start with verbs – we need verbs to do things
    • verbs are a user task – they are a small task
From Agile 2011
  • now we want a flow of what we do from left to right – stack the duplicates and group the similarities – create a user workflow
From Agile 2011
  • mark where the natural breaks are – this is called a user activity – a grouping of things that a user does
  • next, identify where the pain points are
  • because it is a map you can find stuff in it
From Agile 2011
  • 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:

  1. talking to real users
  2. brainstorm user tasks to help them organize
  3. 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)
  • map at MVP (minimal valuable product) and MMF
From Agile 2011
From Agile 2011

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.

From Agile 2011

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:

  1. radar – makes you aware of the people around you, takes confidence
  2. target – figuring out who you want to connect with in an organization, who has the real power
  3. 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
  4. back off a little – the other person may not be ready for the interaction, give the other person space
  5. 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
  6. dance – have a little fun, create conversation – lunch, cook together, virtual coffee over Skype, celebration to mark a milestone, dinner club
  7. get real – go through a crisis together, if you have flirted and built a relationship
  8. 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

From Agile 2011

The acrobatic team doing their trampoling indoors was certainly a highlight:

From Agile 2011

Podcast

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

Agile 2011 Day 1 Review

Agile 2011It 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.

From Agile2011

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

From Agile2011

Things that help: centralised repository, short backlog, story maps, clear business goals, UI mockups part of the story, clear priorities, crisp acceptance criteria

From Agile2011

To set the stage we need:

  • a sponsor, product owner / champion, customer, technology
  • a shared understanding of vision, much like an infinity loop we: discover –> prepare –> deliver
From Agile2011
From Agile2011

They then went on to speak about value:

  • 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
  • up sell revenue potential
  • foundation for long term savings
  • provides revenue for future
  • frequency of use
  • automate labour intensive tasks
  • no viable manual workaround
  • reduces pain for end-users
From Agile2011

This led to a discussion about backlog:

  • we want to build the most valuable things first
  • 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
From Agile2011

And finally onto requirements:

  • product provides value to users – who will receive value from the product
  • what actions need to be performed – what are set options
  • what is the data (noun) and the type and state of data
  • what are the constraints – policies or controls that need to adhered to, business rules

The example for this tutorial was getting to the Agile 2011 conference. We first ask the question: what do we value.

From Agile2011
    • customer value – convenient parking, staying in conference hotel, cheap flights, etc…
    • business value – people stay at conference hotel, one stop shopping on the website to save aggravation for Agile Alliance as well as attendees
    • user roles – travel explorer – individual attendees (speakers, sponsors, volunteers, attendees) and corporate travel agencies for group travel
From Agile2011
    • actions – hotel information, distance to the venue from home, distance from other hotels
From Agile2011
    • data – link to hotel (official hotel plus local hotels), Salt Lake City information
From Agile2011
    • control options – the business rules, such as when you need register by, etc…
From Agile2011
So we start with the requirement:
I need to: register
User role
  Type options: member*, non-member, group, academic
  State options: active*, inactive
From Agile2011

Then the actions:

Action options
  learn
  pay
  confirm
  communicate
  cancel / transfer
From Agile2011

Then the data:

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

From Agile2011

We then need to look at the business rules and prioritise them.

From Agile2011

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
From Agile2011
    • 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
From Agile2011
    • 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
From Agile2011

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.

From Agile2011

Plans in an array matrix – the anchor is the action dimension

From Agile2011

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).

From Agile2011

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.

From Agile2011

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:

  1. Give yourself forgiveness, forgive yourself for being human
  2. Teach this with a light tone. Make yourself the brunt of all the jokes that are below the line
  3. 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
  4. 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:

  1. Resist giving advice. Tell me what you have tried, tell me what you haven’t tried
  2. 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.

From Agile2011

There were heaps for great stories but here are some of the snippets I took away:

  • started with XP Immersion
  • at the XP Leadership meeting, rejected idea of creating a group
  • Bob Martin and Martin Fowler sketched out an idea for the Lightweight Methods conference
  • 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
  • consider lean inside the same heritage as agile
From Agile2011
From Agile2011
From Agile2011

A reunion site has been setup in conjunction with this event.

Podcast

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

Agile Australia 2011 Day 1 Review

Agile Australia 2011Agile 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

Alistair Cockburn delivered this keynote, the slides are available here.

From Agile Australia 2011
  • agile software development is for wimps
  • 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

From Agile Australia 2011
  • 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
  • old business techniques have reached their use by date (Gary Hamel – Management 2.0)
  • 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
  • in 1968/69 NATO held a conference to address a perceived crisis in software engineering – sound familiar?
  • 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.

From Agile Australia 2011
  • 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.

From Agile Australia 2011
  • in the software world we deal with known unknowns
  • spikes are your friends, purely informational gathering
  • ckjm – tool for reporting complexity and coupling
  • 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.

From Agile Australia 2011
  • 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.

From Agile Australia 2011
  • a perfect team is one that can do anything, in control, do anything thrown at them
  • lots of teams act in an agile manner, the leader makes the difference
  • Robert Greenleaf – The Servant As Leader – others highest priority needs are being served first
  • 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.

From Agile Australia 2011
  • 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

Panel – Continuous Delivery

Evan Bottcher, Neal Ford and Martin Fowler from ThoughtWorks were on this panel.

From Agile Australia 2011
  • 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.

Also, I have to send congratulations to my colleague Adrian Smith from Ennova on his talk Agile for Startups which I hear was very well received (I have attended previous incarnations of this talk).