There are many people currently discussing the difference in the roles in the Agile world - indeed only this week I read a post suggesting that a Scrum Master was also an Agile Coach (why not eh!). Within that conversation were a range of nuances between what makes someone an Agile Trainer rather than a Coach. As someone who does a bit of both of those I have given this a level of thought.
Personally I think a lot has to do with the mindset of the individuals involved and what their personality traits are. A Trainer will typically be in the glare of a projector in front of a group of willing (or conscripted) attendees who are keen to learn something (or add a tick on their PDP). A Coach on the other hand will often be found sat at the back of a room and observing what is going on, then quietly adding course corrections or advice as things progress through a workshop or session.
To me, these are different skill-sets and therefore there is a distinction between the roles; however whilst looking for a more firm and empirical answer I found an old blog post by Pierluigi Pugliese which hit the nail on the head for me.
He identifies that a Coach is responsible for controlling a process without necessarily adding any new information. The Coach should be able to ask the right questions and make sure the recipient team is moving in the right direction toward their own objective. The recipient team is normally providing all the content themselves. The more the Coach keeps the process moving along and resists him or herself from providing content in the discussion, the more effective they will be.
Why I really like this concept is that it clearly distinguishes Coaching from Training. In Training the goal is specifically to provide content to an audience who need new knowledge.
To quote Pierluigi directly:
"A Coach, content-free, opening new options and solving the blocks the Client (be it an individual or a team) has. This means driving the Client through a discovering process where she will find new options to deal with old problems."
"A Trainer, explaining the content of the various methods ... The silent assumption here is the Client is less knowledgeable in what she is being trained in and she will have to re-elaborate the material through a practical experience."
This means that ultimately "what is a Coach and what is a Trainer" is basically just the wrong question. There are simply a couple of different requirements: people needing Coaching and people needing Training.
These certainly could be fulfilled by the same person who has the requisite skills; or indeed by different people who prefer just providing one of the "ing's" and not the other.
Actually once this differentiation is made, you may find you are Coaching on one daily conversation and Training in the next!
Friday, 6 January 2017
Saturday, 3 September 2016
Do more Less - in fact do much more Less
In my last assignment I found myself in a company in denial. After two years on their agile journey they thought they were making progress, they weren't.
Despite being given some basis agile/scrum training (the classic 2 day course) two years prior, there had been no-one to mentor in the behaviours and best practice that actually make Agile work. TFS has been implemented and deemed to be "Agile" so therefore job done eh!?
This meant that Agile was not actually in existence. The Business were not engaged, stories were not being written well (actually most were awful), there was no pairing or Agile best practice in development and there was a massive silo culture of Development and then Test. This "wall" between them meant that each item being delivered simply followed a waterfall design/build/test process within an arbitrary wrapper called a "Sprint".
The really sad thing was that no-one was happy. Developers were stuck in big tasks (20-plus point stories being played) and over-engineering what needed to be done. Testers were building out test plans to give as much coverage and risk reduction as they could to the work and would only see the app after Dev had finished it and moved it to another environment for testing. Also the Business was not releasing anything at all and had basically seized up.
One thing that immediately struck me was that apart from the complete breakdown of scrum, there was way too much being done. Lean principals in software development and testing had not emerged anywhere and there was a BDUF mentality. Developers were waiting on Architects to "design" what they needed to implement and Testers were waiting on Developers to build this design. This lead to over-architecture, too much development (lets fix/replace this at the same time) and then Testers were building massive test catalogues to attempt to give coverage across everything that was being built or refactored.
What did this mean?
Q: "How long to change this single report template?"
A:"A week to build and two weeks to test"
I heard testing estimates of up to three months being given for what were very straightforward changes, often driven by the fear factor (unfounded!) that the whole platform would break if someone waved a keyboard near it so the whole thing would need manual regression testing.
I needed to fix this and I coined the phrase "Do more Less.." (e.g. Do more Less Testing) and set about unpicking the pervading culture and concerns that it was all too difficult, and that everything would go wrong if absolutely everything wasn't risk tested surrounding every user story.
I got the product owner re-engaged, got the user stories back to a small "proper" size and format, then encouraged the testers to create small simple tests that only covered the contents of each user story (this immediately sowed the seeds for some TDD too). Once we were in this position I then encouraged (well, bullied) the testers to work with the developers and begin testing in the Dev environments as soon as the code was being crafted, rather than waiting to see it on another environment once finished.
Guess what, everything started to speed up. Testers were spotting errors within minutes of them being coded or spotting ambiguities in the requirements which analysts could iron out; Developers were focusing much more on the smaller stories and not getting bogged down in wide-ranging architectural change; the product owner suddenly had tangible things to see at show and tells (which had fallen by the wayside a long time prior) and "Agile" practices began to emerge.
Coming back to the point of the post though; in getting the teams to work on much smaller things, and do the minimum needed to deliver them and assure their quality (rather than worry about everything around it), they were doing less work per story ...a lot less. This in turn enabled everyone to do a lot more of Less work which in turn meant productivity went up, the team literally was delivering three times faster and everyone was suddenly a lot more cheerful about Agile!
Do more Less ..much more of Less. :-)
Despite being given some basis agile/scrum training (the classic 2 day course) two years prior, there had been no-one to mentor in the behaviours and best practice that actually make Agile work. TFS has been implemented and deemed to be "Agile" so therefore job done eh!?
This meant that Agile was not actually in existence. The Business were not engaged, stories were not being written well (actually most were awful), there was no pairing or Agile best practice in development and there was a massive silo culture of Development and then Test. This "wall" between them meant that each item being delivered simply followed a waterfall design/build/test process within an arbitrary wrapper called a "Sprint".
The really sad thing was that no-one was happy. Developers were stuck in big tasks (20-plus point stories being played) and over-engineering what needed to be done. Testers were building out test plans to give as much coverage and risk reduction as they could to the work and would only see the app after Dev had finished it and moved it to another environment for testing. Also the Business was not releasing anything at all and had basically seized up.
One thing that immediately struck me was that apart from the complete breakdown of scrum, there was way too much being done. Lean principals in software development and testing had not emerged anywhere and there was a BDUF mentality. Developers were waiting on Architects to "design" what they needed to implement and Testers were waiting on Developers to build this design. This lead to over-architecture, too much development (lets fix/replace this at the same time) and then Testers were building massive test catalogues to attempt to give coverage across everything that was being built or refactored.
What did this mean?
Q: "How long to change this single report template?"
A:"A week to build and two weeks to test"
I heard testing estimates of up to three months being given for what were very straightforward changes, often driven by the fear factor (unfounded!) that the whole platform would break if someone waved a keyboard near it so the whole thing would need manual regression testing.
I needed to fix this and I coined the phrase "Do more Less.." (e.g. Do more Less Testing) and set about unpicking the pervading culture and concerns that it was all too difficult, and that everything would go wrong if absolutely everything wasn't risk tested surrounding every user story.
I got the product owner re-engaged, got the user stories back to a small "proper" size and format, then encouraged the testers to create small simple tests that only covered the contents of each user story (this immediately sowed the seeds for some TDD too). Once we were in this position I then encouraged (well, bullied) the testers to work with the developers and begin testing in the Dev environments as soon as the code was being crafted, rather than waiting to see it on another environment once finished.
Guess what, everything started to speed up. Testers were spotting errors within minutes of them being coded or spotting ambiguities in the requirements which analysts could iron out; Developers were focusing much more on the smaller stories and not getting bogged down in wide-ranging architectural change; the product owner suddenly had tangible things to see at show and tells (which had fallen by the wayside a long time prior) and "Agile" practices began to emerge.
Coming back to the point of the post though; in getting the teams to work on much smaller things, and do the minimum needed to deliver them and assure their quality (rather than worry about everything around it), they were doing less work per story ...a lot less. This in turn enabled everyone to do a lot more of Less work which in turn meant productivity went up, the team literally was delivering three times faster and everyone was suddenly a lot more cheerful about Agile!
Do more Less ..much more of Less. :-)
Friday, 3 July 2015
Tools don't make you Agile
So this is my mug from a recent assignment. We were all issued one within the Capability Team but it was supposed to remind us all that when we'd finished all our stand-ups, facilitation workshops and face to face interactions, that at the end of the day we needed to update our supporting toolset.
The challenge with adopting Agile is that you need to learn new agile values, and its not easy. Giving developers or technologists the choice of interacting with business people or playing about with a new toolset there is often a sway towards tools and insular practices.
In Agile, its all about the people interactions and conversations that make you more Agile, and you can get the most of them happening when you have an agile wall / 'radiator board'. These walls tell their own story about the status of any project and will attract any interested parties like moths to a light bulb. If this board is in a collaborative space it will encourage the business and technology to openly engage with it and with each other. The six conversations* you're going to have about each user story are easily enacted in this space with physical media (cards and pens) rather than a screen.
If you use desktop tools you promote people to look at their own screens rather than each other. I call desktop tools 'fridge's' as you've got to open them to see what's inside, unlike your Agile wall that is always radiating information. The human brain can happily manage about 150 items in view and in context on a wall, so only got for a supporting toolset if you're way over this amount, or you have specific geographical challenges you can't overcome with other means.
Any organisation that thinks rolling out Rally, Jira or whatever to their tech department is suddenly going to turn them Agile is starting off in the wrong direction. Toolsets can help make your processes more efficient, but they don't make you "Agile".
*A user story is a placeholder for a conversation, one that will take place about six different times before the story gets played into a scrum team.
 |
| Keep calm and update Rally |
In Agile, its all about the people interactions and conversations that make you more Agile, and you can get the most of them happening when you have an agile wall / 'radiator board'. These walls tell their own story about the status of any project and will attract any interested parties like moths to a light bulb. If this board is in a collaborative space it will encourage the business and technology to openly engage with it and with each other. The six conversations* you're going to have about each user story are easily enacted in this space with physical media (cards and pens) rather than a screen.
If you use desktop tools you promote people to look at their own screens rather than each other. I call desktop tools 'fridge's' as you've got to open them to see what's inside, unlike your Agile wall that is always radiating information. The human brain can happily manage about 150 items in view and in context on a wall, so only got for a supporting toolset if you're way over this amount, or you have specific geographical challenges you can't overcome with other means.
Any organisation that thinks rolling out Rally, Jira or whatever to their tech department is suddenly going to turn them Agile is starting off in the wrong direction. Toolsets can help make your processes more efficient, but they don't make you "Agile".
*A user story is a placeholder for a conversation, one that will take place about six different times before the story gets played into a scrum team.
Subscribe to:
Posts (Atom)