Tuesday, 28 February 2017

Do We Want An Agile Culture? Agile Leadership

Scope:
This article presents a quick look at how one can determine if leaders of an organisation really want to Be Agile.

Problem:
So, as an Agile Coach you have been asked in to discuss Agile Adoption with the leadership of a company.  But how do you know if they really want to Be Agile or is this just another tick box for senior management? Cloud, DevOps, Agile, Open Source etc.

Idea:
I recently attended the CAL1 [1] course by Michael Sahota [2]. If you have not been on this course you really should go, it was amazing and insightful. On this course Michael provided a Play-Book For Inviting Growth.

I adapted this play-book for determining if the leaders of an organisation really wanted to have an Agile Culture like so:

Culture Play-Book
My simplified version of the play book flow is as follows:
  1. Do you want to Grow your organisation?
  2. If so, why do you want to Grow it?  (Profits? Market share? Innovation?)
  3. Drop the word Agile as it has too many connotations
  4. Raise awareness Externally and Internally of the change coming
  5. Do you want to change Culture? If not then Tactical or Strategic is whats left
  6. If you want Culture change you should orient towards a known Model (Teal, SDi, Sahota's model)
  7. Leaders must Go First on this journey or no one else will
Number three may seem controversial but is Agile really the Goal?

Once we determine that the Goal is not Agile but another leadership reason then we can focus back on the real Goal. This leads us to an diagram from Michael on what is your focus for change?


What Is Your Focus? Micheal Sahota [3]
As we can see from the diagram Tactical and Strategic benefits are at the top, but it is Culture which has the break through results. And Michael's model of what Culture looks like:

Culture Model Micheal Sahota [4]
Finally Leaders must go first. And as we are all leaders in one shape or another we all learned a lot by being one of the first people to go on the CAL1 in the UK.

Here are some photos of my class that learned so much by going first!

Micheal Sahota trains the CAL1
Group Discussion on Culture
The Agile Hand of Stop Talking!
Micheal takes us on another journey of learning!

Which Metrics Work? Go on the CAL1 and find out!
UK Class of Feb 2017 

Tuesday, 31 January 2017

Speakers what to do at Conference? - Regional Scrum Gathering Porto


Scope:
This article presents a quick lightening view of what to do when attending a Conference as a Speaker. In this case the Regional Scrum Gathering Porto December 2016 (also known as Agile Connect) [1].

Problem:
When you get asked to present as we did last December, do you as some, cruise by, do your talk and then leave. Like the Panda do you eat shoots and leaves.

Or do you …..

Solution:

My co-speaker Chris and myself were invited to deliver a talk on Coaching Scrum teams [2]. While we had been selected for the Saturday, I decided to take personal time off work and arrive early to experience the Conference for the full three days.

This decision proved to be of awesome value. Not only did I get to meet many great new friends, but I also got to experience the wonderful city of Porto which is truly beautiful.


Porto

Porto Station
Then there was the presentation itself. It went really well and we had great feedback. Of course it does not always go this way. I believe this was down to the support of the organisers of the event. They truly looked after us. Great Scrum Masters all of them.

Speaking in Porto
Flaming food in Porto at the Speakers Dinner

The experience showed me that a speaking event is more than just the conference, it is the community, it is the speakers, it is the organisers, it is the people that makes it worth going too. Whatever reason you go to a conference, make sure you talk to the people. As they are the conference.

Chances are they will have the Agile mindset and you will learn great things as I did.

Agile Link: 
Being part of the Agile International community.
References:


Monday, 26 December 2016

How to Become a Successful Agile Conference Presenter


Scope:
This article show cases my experience at becoming an Agile Conference presenter. Specifically at Agile Tour Vienna 2016 [1].

Problem:
These days if you have something interesting to share, Agile conferences seem the best place to do this. However how does one become a conference speaker? Originally I applied to a Scrum Alliance Global Gathering [2], but I was rejected. So, failed at the first hurdle.

For my first submission I did not back check the previous conferences topics to see what type of presentations had been selected. The type of talks the particular conference likes. I also targeted one of the top conferences/gathering. Competition was too high against very experienced presenters. I had no chance as an unproven new comer. Why would they the organisers take the risk? They did not.

Solution:
What I learned from the failures ended up becoming the solution to the problem. Inspect and Adapt [3].


To even be considered for selection one has to create edgy and interesting talks. Otherwise why would anyone take a risk on you?

What I have noticed is that if you look at many conference sites you can see the type of talks which are in fashion. At time of writing these seem to be Agile Transformations, Agile Coaching approaches, Scaling frameworks, big name sexy companies like Spotify, Google, Thoughworks etc. Even if you do not work for these companies, by having a talk about them seems to generate interest.

Quite a few conferences allow multiple submissions. So, having a few abstracts pre-built and ready to go will obviously increase your chances. They will also show the organisers that you really want to present at their conference.

I found selecting Agile conferences abroad also increased selection as the organisers liked to have foreign speakers to make their conference look international. It also meant you as talker would soon become an international speaker. And most importantly the attendees may get a different perspective than they usually would get. However there is a catch and that is as you are unproven and not a name you will have to pay for your travel, accommodation, food and local transport yourself. So, this activity is not free until you become a name on the circuit.

Agile Tour Vienna 2016
Check past talks to see the type of speakers and submissions they have been known to select. Then you can selects the ones closest from your ready list. Then submit probably no more than 3-5. Some conferences like the Scrum Alliance ones limit to two!

I have created a list of activities I go through to increase my chances:

  1. Create abstracts for submissions and make them interesting, edgy and topical.
  2. Have several abstract submissions for talks readily available.
  3. Select small Agile conferences abroad.
  4. Be prepared to pay your own way on travel, accommodation, food and local transport.
  5. Align content to past conference subjects as then you can guess what they like to select.
  6. Submit more than one talk, as many as you can.
  7. Always ask for feedback on rejection and if you get the response “there were a lot of high quality presentations”, then respectfully ask for more detailed feedback than that. This way you can learn from that feedback and improve.

Proof of this success is a talk I conducted with Chris Nikitas for Agile Tour Vienna 2016 entitled Large Scale Agile Transformations (in IB): Lessons Learned” [4]. This was the first talk I have performed in the community. Using the approach above I have since conducted many more talks. Here I present:
  • Agile Tour Vienna 2016 submitted abstract [5]
  • Video of the talk at the Conference [6]
  • Actual Slides from the Talk [7]

Agile Link:
Sharing knowledge is the best way we can as a community improve the change of mindset in anyone and everyone to that of Agile Mindset.

References:
[1] Agile Tour Vienna 2016: http://agiletourvienna.at/
[4] Large Scale Agile Transformations (in IB): Lessons Learned: http://agiletourvienna.at/#scheduleModal-large-scale-agile-transformations-in-ib-lessons-learned
[6] Video from: Large Scale Agile Transformations (in IB): Lessons Learned:
https://vimeo.com/196583982
[7] Slides from: Large Scale Agile Transformations (in IB): Lessons Learned:

Monday, 21 November 2016

A review of “Training From The BACK Of The Room”

Scope:
Recently I attended a course with a long title of “Training From The BACK Of The Room” [1]. It was a wonderful event and has helped me a lot in so, many different ways. I went on this course as there was a problem I was trying to solve.

Training From The BACK Of The ROOM!
Problem:
As an Agile Coach I have learned over time that the main change required as core to an Agile Transformation of an Enterprise organisation is that of Culture. Instead of mere working practice. Culture means changing the mindset of the many.

It seems to me that one of the best ways of changing a mindset from Command and Control to an Agile Mindset is if the people learn how to do this themselves. But before that even happens they will need some help with Agile Fundamentals. The basics to get them going as a mindset fundamental. Hence the name.

This means someone needs to train them. Now while I have done training before, I always felt it could have gone better. Thus I needed to improve my knowledge first before improving anyone else’s knowledge.

Solution:
I had heard about such a "train the trainer" course that would improve your training skills. With your learners being the focus. It is called “Training From The BACK Of The Room” created by Sharon Bowman [2]. Then I was also fortunate enough to attend such a course which was being trained by James Enock and Nader Talai. Who had been taught by Sharon herself.

The course started totally differently from every other course. The trainers did not directly instruct us, but directed to sit at a table and write our name on a label with a sign like so...

Learner Greeting Instructions
Each table also had a copy of the workbook and box with all the equipment that us as learners would need for course. Post it notes of all sizes, Sharpies, stickers, colour A4 paper and some weird toys! On the walls were various learning tools, which we would come to use later.

It should be noted that This training requires a big room, a very big room. There were only 10 of us, the room usually holds 20 plus for training. But later we discovered we needed the room as there is so, much to do. We used every part of it.

Group Presentation
In Sharon’s training, the learner chooses the areas of interest. Therefore the learner directs their own training. Thus we were asked to vote on 9 learning areas using a Dot-Voting technique.

Learners Dot-Vote For Learnings
More tools were explored and then we went into how to plan a session using the 4C’s Map, which covers:
  • Connections
  • Concepts
  • Concrete Practice
  • Conclusions
In the photo you can see the explanations of these in the supplied Participant Workbook and also the complementary books you get with the course.

4C's MAP and Sharon's Books
And it continued on into the second day whereby we would direct our own learning on exercises and understand how learners learn best with Sharon’s teachings providing a very large collection of training tools. We also covered the Brain Science [3] behind learning with the concept of the Pinky Brain [4].

We then had to use the 4C’s Map to develop our own one hour training session. Here is me demonstrating my training plan for the Agile Mindset. The outcome was not that the learner just learned, but that they could explain it to someone else. This way we know they have really understood the subject matter.

Presenting my session plan using 4C's
In summary this is one of the best courses I have ever attended. Both of the trainers worked in harmony keeping to Sharon’s approach and I felt I had learned so, much that it motivated me to learn even more. Most of all I shall be putting this into practice immediately so, that my learners can benefit too. A massive big thank you to Sharon, James and Nader for this enlightenment.

The class with James (Centre) and Nader (far-right).

Agile Link:
Many Agile, Scrum and Kanban trainers have been on this course and recommend it highly. It seems to have became widely attended across the Agile community.

Sharon has also produced an Agile Manifesto for Accelerated Learning as was displayed on one of the walls.

Agile Manifesto for Accelerated Learning
I think Mindset will need to be put on my Agile poster [5] as a future update.

References:
[4] Pinky Brain: https://www.yumpu.com/en/document/view/43389793/gauss-n-x-n-1-2-myth-about-learning-brain-sharon-bowman/4
[5] Agile Development Poster: http://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html

Tuesday, 11 October 2016

Creating an Internal Agile Coaching Capability

Scope:
Recently I attended the Scrum Coaching Retreat Geneva 2016 [1]. It was a great event, mainly due to all the beer drinking. The pipe in the middle below is 5 litres of beer. We were happy ;)


Chris, Rickard, Tom, Mark, John

But back to the title, while we were there we identified a problem within Agile Transformations.

Problem:
The problem is when all the external Agile Coaches arrive, they often leave with more knowledge than they started with. Which is okay for them, but their clients are often left without any internal Agile Coaching capability.

Just like a diet when you come off it you go back to bad old habits and get fat again [2]. So, organisations need to develop their own internal Agile Coaching capability. But how do they do that when they do not have it in the firs place?

Solution:
The solution we came up with at the Retreat was a brand new programme that would train and coach the internal people. Thus growing their capability over weeks and months. It would not be a quick course and then failure. It would be an academic programme of learning and development.

This was done over several sprints within the event, in conjunction with 3 Agile coaches and 3 CST's from the Scrum Alliance.
The end result was an actual output whereby the participant would learn and grow over time, gaining skills and experiences. But they wouldn't have to wait until the end to gain the first benefit. Value would be obtained as they went along. Fruits could be be picked from this Agile tree of knowledge. Such as CSP, CTC and so on. 

The original design at a high level (we went into more detail, such as LO and so on) looked like a tree of knowledge with fruits that could be obtained as you progressed.

Tree of Knowledge

While this was only MVP 1.0, as a group we have decided to take it forward as a whole programme or work. We named it the Agile Coaching Academy. You can find the link below [3]. Watch out for MVP 2.0 as it progresses :)

Agile Link:
Its all Agile baby!

References:
[3] Agile Coaching Academy: https://agilecoachingacademy.org/

Wednesday, 28 September 2016

Agile Team Agreement

Scope:
In Scrum we have the DoD and also if added the DoR. However these set of explicit policies as KanBan would say are made by the team are with a focus on the Product. What about something for the team?

Problem:
We need an Agile Working Team Agreement. But what is an agreement? Who creates the agreement? How do we maintain it? Why do we even really need one?

Solution:
As per usual long before I became enlightened, within a wonderful info poster someone else has already came up with an Agile Working Team Agreement.

However  here I hope I answer some of the questions above by expanding upon the original info-graphic [1].

What is a Work Agreement?
Work agreements aim to forge commitment and an agreed upon shared approach that will help the team meet their goal. The team agrees to follow this as much as possible to make themselves more efficient and successful.

The working agreements do not have to represent a check-list and do not have to tie back to the product. They are sustainable agreements that help the team identify core values and build a shared understanding of what it means to work as a team. They are for the team not the Product and thus are different from the DoR or DoD.

Who creates and owns the agreement?
Team members themselves create and own it. The team also reviews them periodically during retrospective meetings. They set the agreement because we want teams that are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

Why would a team need an agreement?
  • To develop a sense of shared responsibility
  • Increase members’ awareness of their own behaviour
  • Empower the facilitator to lead the group according to the agreements.
  • Enhance the quality of the group process
What is the best time to organize this meeting?
Just before the very first Sprint starts and from then on review within the Retrospective meetings. These can also be separate meetings by themselves.

Where should it be placed?
  • Somewhere visible by the team.
  • Next to the KanBan board.
  • On the wiki. Printed out and stuck on the desk of every team member.
  • Tattoed on the left arm. Right arm can be used for the next version and then laser the left arms old version away. From then on swap between arms :P

Agile Working Team Agreement example:
  • Show respect
Don’t interrupt; let people finish what they’re saying. It’s OK to disagree with each other. No personal attacks, attack issues, we debate the merit of ideas, not people. You can be wrong and that’s okay.
  • Contribution
Everyone has an equal voice and valuable contribution. Use every work activity as an opportunity to learn. We make decisions together as One Team.
  • Team Meetings
Be on time by arriving before time (it is the only way), end on time, have an agenda, take away an outcome.
  • Be transparent
No hidden agendas. We will give feedback, we will receive feedback, and we will act on feedback.
  • Impediments
Solve roadblocks within the team. If the impediment cant be solved within the team, give it to the Team Lead to take away.
  • Make commitments as One Team
We as a team will be held accountable to our commitments. – we work as a team to make a commitment and deliver on it. Remember this is the team not one person.  Help the team achieve their task and team-work goals. There is only the team.
  • Incomplete work items are not valuable
It is better to help get an existing work item to “done” than to start another that can’t be finished in the current sprint. Value is what needs to be produced not allocated activity.


Of course agreements will evolve over time and adapted when they are inspected.

Agile Link:
It's for the Agile team and is represented on my Poster by the back drop of One Team [2].

References:
[2] Agile Poster:

Wednesday, 31 August 2016

Agile Pragmatists: Their Latest Excuse


Scope:
I attend many meet-ups and have noticed that the "Agile Pragmatists" [1] are back. Their latest reasoning not to be "purists" as they would put it, is Agile at scale. I often hear the line:
"But this is scaled Agile"
Problem:
The problem with this is that the understanding that Agile is a Mind-Set not a mere process seems to have been lost again.
Agile Mind-Set from ICAgile [2]

How do we get back to Agile as a Mind-Set and away from a purists vs pragmatists battle which no one wins?

Solution:
The solution I believe is education. Once we educate the community that Agile is a Mind-set then it becomes clear you cannot scale one mind, but only many minds. People have to work together, not be fixed and commanded. Luckily it seems I am not the only one [3].

Thus we come to how to educate. Well I would say via the community. Meet-ups, blogs like this. Any avenue to get the message back out there [4].

After this if people still want to be "Agile Pragmatists" as they want to call themselves then they will have to explain what they mean by that alternative Mind-set and how the Agile Mind-set currently does not deliver their so, called pragmatists approach??? If they do manage this, we can then review to see if it is closer to a command and control (waterfall) mind-set [5] than being Agile.

Agile Link:
Its all in the mind :)

References:
[1] Scrum Purists, Posers, and Pragmatists: https://www.solutionsiq.com/scrum-purists-posers-and-pragmatists/

Sunday, 31 July 2016

Agile MeetUps: Be Curious


Scope:
This article presents some examples of an approach to attending Agile Meet Ups.

Problem:
I have attended many Agile meet-ups. In fact I prefer them to conferences as I feel a sense of community. Where as conferences people can come and go.

However I have noticed that at these events people seem to never stretch the topic with the presenter. Most are passive and the ones who do ask questions are few and far between. There is not enough curiosity.

For me this misses a great opportunity to obtain knowledge value from industry veterans. Which seems to be the point of these meet ups, to share knowledge and gain discoveries no?

An opportunity lost.


Solution:
I am suspecting the reason for this is not that people do not know what questions to ask, but rather they do not research the topic beforehand. I often research the presenter before the meet up so, my questions are ready once the Q&A section arrives. One must always remain respectful of course.

Here below are some examples of the questions I have asked:
  1. Fabiola Eyholzer - How can HR adopt an Agile mindset at Adventures with Agile
    Here I asked Fabiola an expert on Agile HR, on an internal mobility conundrum [1].
  2. Craig Larman Q & A - Evening Session
    Here I asked Craig about the Frozen Middle and Dependency Management in relation to LeSS [2].
  3. Lyssa Adkins & Michael Spayd - Want a sustainable agile transformation?
    Here I asked the both of them about a Journey of Coaching [3].
As you can see I ask challenging questions whereby even Lyssa admitted she had been put on the spot. Craig had to eek out, that the answer behind my question was only detailed in his course.

Agile Link:
These questions revealed answers that shared more knowledge with attendees than the mere presentations alone. Without them I believe discoveries for the attendees would have been lost. They have helped progress the local Agile Community.

References:
[3] Lyssa Adkins & Michael Spayd - Want a sustainable agile transformation?: https://www.youtube.com/watch?v=953rtZ9DEYQ&feature=youtu.be&t=4334

Tuesday, 21 June 2016

Coaching the Frozen Middle to be Agile


Scope:
This is an article which presents some quick fire ideas for agile coaching the “Frozen Middle”.

Problem:
The “Frozen Middle” is a term used for middle-management who do not wish to become Agile. They want to avoid this situation at all costs. This is because unless there are incentives, there is nothing in it for them except massive risk. That is their perception anyway.

It becomes a problem as it is middle management who really support and lead real cultural change within an organisation. We need them to be Agile or an Agile transformation will fail.

Some approaches for dealing with the problem of the “Frozen Middle” look at work around process or removal techniques [1]. But this does not deal with the systemic existence of that mindset. The change for the change agents has not really happened.

The problem therefore remains under the surface and is often the reason why a lot of Agile Transformations fail to evolve. They are moderately successful but then hit a ceiling and freeze with no thaw.

Solution:
The solution is one of culture change [2]. To create a new cultural mindset within middle-management. One technique or approach is not enough. There is not a one size fits all. If only!

As with so, many coaching situations it depends upon the details of the situation. This can become frustrating as there is no clear answer, but we can look at some options that together may help us progress a cultural change. Which ones are useful then?

Before coaching can commence though, we actually need to train people in the basics of Agile and also Lean techniques. Often leaders are great at leadership, but have not had exposure to the fundamentals of a topic. Thus they do not know it. However rather than express this as sometimes people can feel this is a weakness, they avoid it. Becoming in denial. They need a starter point as they are Shu [3].

This could take the form of training upon Agile Fundamentals [4] and also the Cost of Delay [5]. Fundamentals explains what Agile is to them and Cost of Delay is nice starter of why they need it. Then we can move onto the "Coaching" and look for Ha and "Mentoring" for the Ri.
ShuHaRi
ShuHaRi [4]
After which we can provide:
  • Coaching on immediate Goals.
  • Coaching on organisational structure.
  • Coaching on adding Business value.
  • Coach them to learn all by themselves.
  • And many other topics as they arise [5].
    We need to be curious when coaching them.
One major caveat that should be in place beforehand is that there must already be an Agile Transformation vision being endorsed and championed by the senior leadership. If Agile has to bubble up, it will fail as it is not seen as addressing the wishes of executive. You always need to "feed the machine".

The end result is that we can help middle management change themselves faster 
through coaching and thus treat them with respect by following the…….

Agile Link:
Agile Manifesto where it states:
“Individuals and interactions over processes and tools” [6]
Processes and tools can help but as they are Individuals too, this is why we need through interactions Coach the Frozen Middle to be Agile.
This is also evident on my Agile Poster as Value of Respect [7].

References:
[2] Galvanize the “Frozen Middle”: http://lithespeed.com/lean-pmo-galvanize-middle/
[4] Agile Fundamentals training: https://icagile.com/icagile-certified-professional
[8] Agile Manifesto: