The Agile Coach is a critical role in helping leaders, teams or individuals understand, adopt and improve Agile methods and practice. Additionally, an Agile Coach helps people rethink and change the way they go about their work. For a individual to be effective in a coaching role, they must poses a wide range of skills and experience. In this workshop we will explore Agile coaching skills in the context of a competency framework and provide participants with lessons from real-world coaching experience. The workshop will provide an opportunity for participants to learn about coaching, identify areas of Agile development and to broaden skills through hands-on group and individual exercises and games.
You will:
» Understand role of an Agile coach and the typical development pathways
» Identify personal areas of strength/weakness in relation to a broad range of Agile and related skills
» Learn situational specific coaching techniques for common Agile dysfunctions
» Understand the use of maturity models in helping teams learn and adapt to Agile
» Understand organisational and role specific Agile challenges
» Learn how to adapt Agile practices to suit team specific challenges
“The aim for any company is for everybody to gain – shareholders, employees, suppliers, customers, community, the environment – over the long term” – Deming
The myth "if you can’t measure it, you can't improve it" is easy to bust. Babies learn to walk without metrics.
I first started using Yammer back in 2009 after hearing about it winning TechCrunch50, and was user number 1 on our company domain (now we have thousands of users). Its been interesting to see the organic growth from the first time I used it (I had nobody to talk to), to a community of early adopters (who treated it like a corporate Twitter) to its usage now as an important communication channel and groupware solution.
My colleague and friend Teale Shapcott arranged the guys at Yammer to come into our organisation last week to give a bunch of people an informal train the trainer session on “Yammer – Getting Started with Groups”. Steve Hopkins and Ross Hill conducted the session, and here are my notes:
Metcalfe’s Law essentially confirms that things get more useful the more people you have in the group
the problem with email is that if you send an email to 12 people, you get 12 responses!
a Yammer group is an way to replace email in a team (basically an easy way to setup a distribution list)
Yammer are currently launching new things to the site every week
Yammer recently acquired oneDrum. Essentially what this will do is put a Yammer folder on your desktop for Office integration, as well as being able to follow files and get updates when things change.
The point of the training was to help get people using Yammer for collaboration. A good exercise to start is get people to log into Yammer (set up a private group for training) and get people to say hi. Next get people to enter what they are currently working on and then get everybody to respond on others posts to get people familiar with the value of the tool.
Pages are a new feature:
pages are a good way to collaborate and brainstorm on ideas
pages can have 10 editors maximum at the same time. It will auto save. When you publish it will notify all the followers that there is a new draft. You can revert back to old versions
pages are useful for meetings, use an iPad and throw the notes or actions up on a page, you can link actions to people or files as well
coming soon is the ability to mark a page as official
documents don’t need to be run by any person specifically, they are now crowd sourced
groups are like rooms in a house
One thing that is new that I did not know about is that you can now use the share feature to share a message across groups (you used to have to duplicate the message).
In the session, one of the other participants shared their approach to getting their team to use Yammer:
they created a new private collaboration group
it took a conscious effort to use yammer by getting the leader to share things on Yammer, this took a few months
they have seen a massive reduction in email but communicating a lot more
they also created a larger department group as well
gains comfort for people using a team group rather than the All Company feed or a public group
takes time to get the comfort up and you have to make enemies
people for the most part are learning something new
you need leadership and you need to take a hard line about just using Yammer
use followed conversations mode, set their preferences to only follow groups that I follow as it removes the noise – everything you see should be relevant, you also need to clean up the feed and email notifications settings for them
update the information tab and use it for information and quick links
needed to be hardcore and had to keep asking “are you logged into Yammer” in order to cement the habit
direct people to engage with your content, rather than just posting something
use announcements to get everybody in the group
get people to follow a hash tag for things like events
Generation Y folks are good advocates to get on side
As a second exercise, we then created a page and collaborated on out own checklist of an approach and tips to setting up a group. Many of the participants (who I assume were not familiar with wikis or collaborative tools like Google Docs were in awe of seeing people collaborating at the same time).
When introducing groups, you are bound to get resistance, so the Yammer has a bunch of great case studies that cover lots of different team types.
Another use, relating this back to Agile, is one team were using it for showcases by doing a live webcast and getting people to comment on Yammer (also the posting the video to Yammer so people could talk about it later as well). In the vain of standup, another organisation would, on a Monday, start a post on what are you working on this week. There are lots of potential usages for the features of Yammer for distributed teams. Another suggestion was to organise in everyones calendar a YamJam to discuss something on Yammer a a certain time.
Finally, there are a lot of Australian companies using Yammer, and the following videos are worth a look.
So there have been a lot of posts out there about Moneyball and how it directly relates to Agile and the Lean Startup. However, I finally got around to watching the move tonight (thanks to my colleague Renee Troughton for lending me the Blu Ray) and had to note down my own thoughts. There are so many good quotes and scenes from the movie, but here are just a couple of standouts (warning, some folks may consider these to be spoilers if you have not seen the movie!)
Right at the start of the movie Billy Beane is talking to the team owner about needing more money (sounds like the start of any typical traditional project to me!)
Billy: I can’t compete against a hundred and twenty million payroll with thirty eight million dollars. Schott: We’re not gonna compete with these teams that have big budgets. We’re gonna work with the constraints that we have and you’re gonna get out and do the best job that you can recruiting new players. We’re not gonna pay seventeen million dollars a year to players.
And a little later in the scene, Billy sets his goal.
Billy: That’s my bar. My bar is here. My bar is to take this team to the championship.
At the scout’s meeting, their discussion is all about appearances rather than understanding and building a team.
Scout: Ugly girl friend means no confidence.
In that same meeting, I really enjoyed the scene where Billy is in the position of a coach/facilitator and keeps asking them if they understand the problem!
Grady: We’re trying to solve a problem here. Billy: Not like this you’re not. You’re not even looking at the problem. Grady: We’re very aware of the problem. Billy: Okay, good. What’s the problem? Grady: Okay, Billy. We all understand what the problem is. We have to replace… Billy: Good. What’s the problem? Grady: The problem is we have to replace three key players. Billy: No. What’s the problem? Poloni: Same as it’s ever been. We’ve gotta replace these guys with what we have existing. Billy: No! What’s the problem, Barry? Barry: We need three eight home runs, a hundred twenty R.B.I’s and forty seven… Billy: Aaahhh! The problem we’re trying to solve is that there are rich teams and there are poor teams, then there’s fifty feet of crap, and then there’s us. It’s an unfair game. And now we’re being gutted, organ donors for the rich. Boston has taken our kidney’s, Yankees takin’ our heart and you guys are sittin’ around talkin’ the same old good body nonsense, like we’re selling deeds, like we’re looking for Fabio. We got to think differently!
A little later in that scene, Billy is really trying to make the committee think differently, but they are just thinking in the same old ways.
Billy: If we try to play like the Yankees in here, we will lose to the Yankees out there Grady: Boy, that sounds like fortune cookie wisdom to me, Billy. Billy: No, that’s just logic.
I really liked the scene where Billy is talking with Art about his contract. The final line of the conversation reminded me of many wasted meetings.
Billy: Good meeting. Everytime we talk, I’m reinvigorated by my love of the game.
And then there are always the nay-sayers and (in the case of Grady) those who will always try to bring your approach down.
Announcer: Do you see this as a decimation of the whole team? Grady: I think that he bought a ticket on the Titanic. Announcer: Oh, boy! He’s tried to come up with a new approach, my hat’s off to him. It won’t work.
The discussion between Billy and Peter about cutting players was a good reminder of being honest and transparent.
Billy: They’re professional ball players. Just be straight with them. No fluff, just facts. ‘Pete, I gotta let you go. Jack’s office will handle the details.’ Peter: That’s it? Billy: Would you rather get a bullet to the head, or fire to the chest or bleed to death? Peter: Are those my only two options?
There was an interesting little scene regarding soda, that is a good reminder that sometimes you can be penny smart but pound foolish (the little things are sometimes what keeps individuals and teams motivated).
Justice: And how come soda is a dollar in the club house? Cause I’ve never seen it like that. Peter: Billy likes to keep the money on the field. Justice: Soda money? Really? Where on the field is the dollar I’m paying for soda?
The scene where Billy shakes up the team by firing some of his all-stars was the turning point that shows that sometimes your superstars are hiding the real talent (and sometimes you need to do something extreme to make a change). Art is the classic Project Manager in this scene.
Art: Yeah, I don’t wanna go through team rounds, Billy. The line up card is mine. And that’s all, okay? Billy: The line up card is definitely yours, I’m just saying you can’t start Pena first. Art: Well, I am starting him at first. Billy: I don’t think so, he plays for Detroit now.
There are some good inspirational pieces in the film (like when Billy asks Justice to step up and be a leader for the younger guys). This quote is my favourite though.
Billy: Everybody, listen up! You may not look like a winning team, but you are one. So, play like one tonight.
The big speech when Billy is at the Red Sox resonates with anybody who has tried to implement Agile in a team before.
For forty one million, you built a playoff team. You lost Damon, Giambi, Isringhausen, Pena and you won more games without them than you did with them. You won the exact same number of games that the Yankee’s won, but the Yankee’s spent 1.4 million per win and you paid 260 thousand. I know you’ve taken it in the teeth out there, but the first guy through the wall. It always gets bloody, always. It’s the threat and not just the way of doing business, but in their minds it’s threatening the game. But really what it’s threatening is their livelihoods, it’s threatening their jobs, it’s threatening the way that they do things. And every time that happens, whether it’s the government or a way of doing business or whatever it is, the people are holding the reins, have their hands on the switch. They will bet you’re crazy. I mean, anybody who’s not building a team right and rebuilding it using your model, they’re dinosaurs. They’ll be sittin’ on their ass on the sofa in October, watching the Boston Red Sox win the world series.
Near the end, when Peter shows Billy the video about the guy hitting the home run, they starting mentioning metaphors (I was so thinking about the metaphor in XP at that point!)
Also, the Lenka song “The Show” made me think about why as Agile coaches we get up in the morning and do this (plus good to see Australian music in the movie!)
I am just a little lost in the moment
I’m so scared but I don’t show it
I can’t figure it out
It’s bringing me down I know
I’ve got to let it go
And just enjoy the show
For those who haven’t seen the movie, it is well worth the time spent. I hadn’t realised Aaron Sorkin had worked on the screenplay, so for that alone it had to be good!
It demonstrates a good model for engagement, defining the roles as hamsters, crash and burners, the engaged, the disengaged, and the almost engaged. Full engagement is the intersection of the maximum contribution for the organisation and maximum satisfaction for the individual. The video makes a good point that because the “almost engaged” are good performers and a large proportion of the organisation, it is tempting to focus your coaching effort on the other areas that are far more disengaged.
It also has a good model to follow so that engagement happens all the time (not just a survey or once a year thing). Employees need to ACT (Assess, Coommunicate and Take Action), Managers need to CARE (Coach, Align, Recognise and Engage) and Executives need to CASE (Communicate, Authentic, Significance and Excitement).
Craig, Tony and Renee get cynical about Agile, assist the search for 100 voices, talk about some recent posts by Steve Denning on management and Agile and lose count of the dictums.
“I guess the reason that I don’t think the original signatories of the Agile Manifesto don’t own Agile is that I was doing Agile in the 90’s” – Alan Shalloway
A couple a months ago, Adrian Smith and I were asked to put together an article for the third edition of AgileTODAY to complement a workshop we plan to run at Agile Australia 2012. Adrian and I had a whiteboard session, and we put together these 8 tips which will hopefully help aspiring Agile coaches.
Introduction
The Agile coach is a critical role in helping leaders, teams and individuals understand, adopt and improve Agile methods and practice. For new and aspiring coaches, starting a coaching engagement can be daunting. It is easy to become distracted from the original mandate and get embroiled in the issues and politics of the team. The following tips were put together to help Agile coaches stay focused and achieve successful outcomes.
Before beginning an engagement with a team try to define success in terms of measurable outcomes and a realistic timescale. Share the outcomes with the team and sponsor to ensure there is a shared understanding of what you are trying to achieve. This will help clarify your role within the team and can help reduce any fears the team may have about the coming changes. Setting a clear end date will also ensure that both you and the team are clear that the team have to own and understand their way of working.
Showing the team how it is done the first time then supporting them as they take ownership of the new way of working is a great way to bootstrap new practices and build trust in new practices. Role model behaviours you want to see in the team. If there are techniques or technologies you cannot model yourself, you may need to mentor an enthusiastic team member or bring in an expert.
There is always a temptation to get involved and help with the team’s delivery work – especially when you see them struggling. While this may offer some short term help and can be useful as a learning exercise, it is unlikely to help in the long term. Becoming part of the team will also make it difficult to have tough conversations with team members, call-out unproductive behaviours and stay focused on your coaching objectives. Try to stand back, your role is to support the team and let them take credit for their success.
The team has probably faced a majority of the issues long before you got involved. If they are to own the solution after you have gone, it is important to have them involved in the decision making process. Remember you are trying to help the team learn to work without your help. This sometimes means you have to let them make a decision that goes against your best judgement. Teams need to learn by their mistakes (and sometimes their idea works out which means you can learn something too).
People can adapt to change more easily when it happens slowly and they see how it aligns to an overall plan. Additionally, change becomes natural when you are able to create a safe learning environment for the team that encourages experimentation. Try to change the practices that are causing problems first replacing them with simple alternatives. If you take away all the old practices that a team depended upon they can lose their way and not see the dysfunctions for themselves.
Asking questions is a fundamental skill for an Agile coach and can be used to drill down to the root cause of problems a team is facing. Don’t be afraid to ask “why” a couple of times to get to the facts behind a problem or to introduce the elephant in the room. As a coach you are in the privileged position of being able to raise sensitive issues and to legitimise discussion of difficult issues.
Helping the team identify what is important (especially from a customer’s perspective), making it visible and updating it regularly will focus a team. Example metrics include: throughput, cycle time, delivered value and many others. The corollary to this suggestion is that you need to be careful what you measure because you can incentivise behaviour that has the potential to be counter-productive.
Although the Agile journey is important, Agile perfection is not the end goal. What does matter is delivering what your stakeholders want in a sustainable way. For this reason it is important to use Agile maturity assessments and other metrics with care. Helping a team become agile should focus on instilling Agile values and principles, while selecting and adapting Agile practices to help the team deliver.
Summary
Becoming an Agile coach requires a deep understanding of Agile, the confidence to drive change and a willingness for self-reflection. The role of an Agile coach is a rewarding one that allow you to use a wide range of skills across technical, social, business and communication disciplines.
Craig, Tony and Renee talk about the news Scrum Inc style, discuss the coolness of Lego for reporting, chat about Net-Map and discuss the state of IBM.
A couple of years ago I received an awesome opportunity to attend James Bach deliver his Rapid Software Testing course in Adelaide. At the time I was working with Sharon Robson from Software Education to help re-develop the Agile Testing course for the Agile Academy, and she thought it might be good for us to sit in the back. The two day course was awesome (one of the best courses I have ever attended), although the animated debate between James and Sharon over breakfast in relation to ISTQB is one I will never forget either.
One of the great things about the course is that the notes are freely available from the Statisfice site (slides and appendices). Although it is the insight and passion from James that makes the course extremely worthwhile. Unfortunately I did not earn my “testing stars” from James from this course, but I did learn a lot. I recently dug out my notes from the course and here they are below.
the secret – “watch people test” – then follow the patterns
traditionally testers muddled through, as you got more experienced you just muddled better
there is lots of practices yet to be written about
James is “walking through an orchard rip with apples”
“nobody expects a tester to be right about anything” – we are in the evidence and inference business
tester tip – did you do “booja booja” testing? Your answer should be “not by that name”
you test under uncertainity and time pressure – if not you are about to be laid off!, organisations keep testers at minimum number
heuristics – essential to rapid testing, eg. walking into a foreign building – “I’ll know it when I see it”
“creep and leap” – leap is the most outrageous test you can do, creep is to gently shatter the pattern in your mind – creep and leap may fail because you don’t leap far enough or you don’t creep enough
minimum number of cases has no meaning – infinite – no light flashes when you have finished testing / understand the pattern
pattern in the test cases is just the pattern in the test cases, not the program
need to leap beyond imagination
rapid testing is not about techniques – a way of thinking, a set of skills
what do testers do? – they are the “headlights of a project”, don’t need testers in the daylight (no risks)
testers don’t ensure quality of a product, they report the quality of the product
key definitions: quality is value to some person (who matters), a bug is anything about the product that threatens its value
testers represent the people whos opinion matters
defect is a bad word legally; not sure it is a defect when you find it, assumes more than you know (emotional word: bug, issue, incident)
testing and questioning are the same thing
there is a motivating question behind each test (if not, a zombie walk)
first principle – know your mission – allows you to test what matters, gets you more focussed
we are chasing risk
quality criteria – what is important, who are users
curse of expertise – people who know a lot, don’t always see a lot (why you need developers and testers)
need an oracle / result – otherwise you are just touring (an oracle is a principle or mechanism by which you find a problem)
rapid test teams should be a team of superheroes – what is your super power? Seek test teams that have variety
critical thinking – “huh”, “really”, “so” – say these words and you are on the road to critical thinking, you have to make assumptions to get work done
“huh” = what exactly does that mean?
“really” = what are the facts, how do we know it is true?
“so” = does any of this really matter, who cares?
safety language – this desk “appears” brown, have “not yet seen” a number 127 work, when you see this language your brain keeps thinking about the problem (interim conclusion only)
if you have stopped questioning you have stopped testing (and turned yourself into a test tool)
video tape your tests – take notes at timestamps, good for audit when you need that
ask a question without asking a question – make a statement / fact and wait for a reaction
model it differently – look at it in a different way
need to have the ability to slow down your thinking and go step-by-step and explain/examine your steps and inferences
exploratory testing is about trying to de-focus – seeing things in a different way
there is no instruction you can write down that won’t require some judgement from a human
irresponsible to answer a question without knowing some context – allows you to establish a risk landscape
James remembers his testing approach as a heuristic – CIDTESTDSFDPDTCRUSSPICSTMPLFDSFSCURA (his notes go on to explain this one!)
when you hear “high level”, substitute “not really”
HICCUPS(F) heuristic, a set of patterns all testers seem can be an answer to justify why something might be: History (something has changed), Image (OK, but something makes us looks stupid), Comparable products (like another system), Claims (said in a meeting, hallway), User’s expectations (do you understand users), Product (consistency), Purpose (why and what is it trying to accomplish), Statutes (something legal), Familiarity (a familiar feeling)
Oracles – calculator (ON 2 + 2 =4; not heuristic, answer won’t be 5, burst into flames, number won’t disappear), Word saving files (came up with 37 alternatives), Notepad (this application can break, Microsoft suggested it was not a bug)
Ask for testability – give me controllability (command line version and visibility, text version of display), when developers say no send email so you have documented evidence on why didn’t or it takes so long to test
ask “is there a reason I have been brought into test this?”
ad-hoc / exploratory does not equal sloppy
testing is not the mechanical act but the questioning process, only people who have a goal of 100% automated testing are people who hate to test, don’t hear about automated programming (what about compiling?)
everybody does exploratory testing – creating scripts, when a script breaks, learning after a script runs, doing a script in a different way
exploratory testing acts on itself
“HP Mercury is in the business of avoiding blame”
script – to get the most out of an extremely expensive test cycle, for interactive calculations, auditable processes
mix scripting and exploration – what can we do in advance and what can we do as we go, James always starts at exploratory and moves back towards scripting
use a testing dashboard – break down by key components in the system, all management cares about is a schedule threat so get to the point, count the number of test sessions (uninterrupted block of testing time – 90 minutes) as management understand this (session test management), the key is simplicity, what does management usually ask for / need (usually a different measure), counts give the wrong impression, numbers out of context, number of test cases is useless, use coverage (0 = nothing, 1 = assessed, 2 = minimum only, 3 = level we are happy to ship) and status (green = no suspected problems, yellow = testers suspect problem, red = everybody nervous)
equivalence partitioning – you treat differences as if they are the same, models of technology allow us to understand risk (eg. dead pixels on a button), critical tester skill to slow your thinking down (is that a button?)
galumphing – doing something in an intential, over exuberant way (eg. skipping down the street), some inexpensive galumphing can be be beneficial, takes advantages of accidents to help you test better
many people are hired to fake testing – not to find bugs but to point fingers (“we hired testers”)
good testers build credibility
testers question beliefs (we are not in the belief business) – cannot believe anything that the developers tell you
lots of people can test – like surgery in the 14th century
reality steamroller method – maximise expenses from the value that they are going to have – record decisions, do your best to help out, let go of the result, write emails to get your hands clean (helpful, timestamp documented)
get all of the documentation and create a testing playbook – diagrams, tables, test strategy
calendar exercise – visualise your test coverage whenever you can, plot times on a grid, bar chart, wheel
choose a number between 1 and 20 – 17, 7, 3 – 20 is the least popular – what about pi, floating points – choose because they look less random
bugs with data types (eg. string in JavaScript) and bugs in tables and labels not found by boundary tests – this is when you need to run inexpensive random testing
anti-random testing – heuristic – every molecule trying to get away from the other molecule – as every test is trying to do something different
finding bugs – testing exhaustively, focus on the right risk, indulge curiosity, use a defocussing strategy
curiosity – urge to learn something you don’t need to know
good usability checklist (medical devices) – ISO 60601-1-4
base testing on activities (what a user does) rather than on test cases
playbook – table – goal, key, idea, motivation, coverage, etc… – is just a list of ideas
you can’t check an always – but you can test aggressively for confidence
stopping heuristic – piñata heuristic (when you have enough candy), cost vs value (when cost exceeds value), convention (what is expected of you), loss of mission, ship
basic boundary is testing is not one over / one under –> fairy tale boundary testing
My workshop from Agile Australia 2012 with Adrian Smith called “Agile Coaching Workshop” is available on SlideShare.
Craig Smith 
You must be logged in to post a comment.