At the March 2017 Agile Brisbane meetup, we were lucky to have Pat Reed, an internationally recognised Agile transformational leader in Adaptive Leadership and Value Innovation, present on “Business Agility: Creating the Future”.
She provided a copy of her slides, and here are my notes from the evening:
- Every leader at eBay (440 of them) are Agile Coaches, it’s the third round now for them, imagine the change if you get frozen middle on board
- We need to thrive through uncertainity
- Elon Musk practices first principles ways of thinking
- Compasses are what we need to thrive on uncertainity, we cannot leverage maps because it is an unknown future
- Don’t do more with less, do less, to execute in uncertainity
- Change is changing, we need time for learning and innovating
- If you demonstrate belief in the team and give an environment of safety, the team will believe in their potential – stop telling teams what to do, ask them what they think what we should do
- Safe to fail is critical – we were all born with an Agile mindset (Carol Dweck) but our work and experiences push us towards a fixed mindset – if people can’t learn and thrive, your transformation will fail – as a coach we need to provide air cover
- Keep timelines short all the time – the size of the iteration accelerates the learning cycle and the faster the learning
- Using David Marquet’s Ladder of Leadership model at Ebay – cards you can download, when your employee says this, you say that
- NeuroLeadership Institute – “Why Organizational Growth Mindset Matters“
- An adaptive framework – believing is seeing at centre, need to see awareness and understand the problem, need to process options through discovery (really short time frame, as for 3 value experiments), taking action (learn by doing not thinking), transform learnings into collective knowledge
- DTA has some great tools around discovery
- There is a cost to value, we won’t do anything that doesn’t have x% value, we need to stop being order takers and become value shapers
- Principles for Navigating the Future (Joi Ito) from the Media Lab at MIT, doing interesting stuff
- Your organisation is not a machine, you can’t fix it – most organisations are setup to work how they were intended to work
- Innovation, growth and transformation does not happen without tension – learn to identify good and bad tension
- What could we do if we knew we couldn’t fail – embrace that
- Do Stanford free Design School program online – same as the expensive in person program
- Polarity Management – polarity is when you think you nailed a wicked problem and then it comes back to bite you, need to find the best win-win from any scenario, if you try to solve it traditionally you make it worse
- VUCA is here to stay, learning is our competitive advantage
- Microsoft’s CEO Sent an Extraordinary Email to Employees After They Committed an Epic Fail
- Measure real value, speed to value and cost of value, need relative value not precision because it doesn’t serve us – Case Study and spreadsheet to calculate value
At 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
- 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!
At this month’s Agile Brisbane meetup, Ben Starr presented on Lean Metrics. His talk was based on metrics that they tracked at his previous company on an operational support team. A couple of points from the talk:
- used Kanban – work item types to allocate capacity and 3 levels of service (standard, coordinated, expedite)
- JIRA was the tool but was not the most ideal choice and not really up to the task
- reported by type on backlog, work in progress, throughput (number of work items not size), velocity (throughput and velocity were similar which showed average size), cycle time, class of service mix, due date performance, estimation accuracy, cancelled WIP (started and then cancelled work) and demand balancing (clearing out the backlog)
- flow efficiency – percentage of time you work on an item versus in progress, also referred to as touch time – using time tracking in JIRA to do this
- time allocation – value add, failure load (defects), transaction cost (overheads of planning and releasing), coordination cost (management), used percentage of time spent rather than actual hours
The one things that got me thinking during this presentation was the flow efficiency report.
Early on my journey of being an Iteration Manager, my teams used to track times per card. We used to use XPlanner which had some reasoanbly easy functionality for tracking time (one of the good features was as the Iteration Manager I could enter time for my team if needed, tools like JIRA require the developer to record that data if you want it assigned to that developer). We used to use thee metrics for comparing estimates to actuals but over time I came to the conclusion that we would be much better off just making sure that the cards were completing on time (an average of 3 times) and splitting cards out if they appeared to big.
Lately, a number of people in my Agile classes have been arguing that time track is beneficial. My usual response to this (like for all metrics) that it is OK if it adds value, but my recommendation is not to waste your time. Even more so, this opens up the estimation debate that I also believe that a lot of time should not be wasted on (#noestimates), but that is a discussion for another post. My main reasoning is often we need to track for other sources (like timesheets) in different systems, and the overhead does not justify the effort. If teams need time metrics (often to see if time is being wasted away from the core work of the team, say on production support or corporate meetings), I suggest they are done at a team level and rounded to the nearest hour, and collected as time not spent not on project work.
In the graph above, flow efficiency is a good way for showing waste in the system (in this example, the team could potentially be way more effcient), but it relied on the team tracking time (in this case using the time tracking feature in JIRA against each card). I really like it as a graph, I am just not sure the effort to produce it is justified.
Some discussion in the Q&A revolved around recording time tracking (or similar metrics) is OK if the team understands it is an incentive for better metrics, and I can’t disagree with that thought. Just in my experience as an Iteration Manager, getting reliable and timely time and effort metrics ha been painful and the reward outweighed the effort.