What topics do you think are essential in a 1 day Agile introduction training ?

[bruno...@cegeka.com]

Hello all,

"What topics do you think are essential in a 1 day Agile introduction training ?"

I'd like to use your feedback on above question to challenge/renew our existing Agile introduction training.

Looking forward to your feedback, I'll make sure to post the final updated topics list we identified for our training in this thread.

Note: I was pointed to this interesting forum by my college-time friend and fellow coach Yves Hanoulle (Tx Yves).

[Ron Jeffries]

Tell us who the audience are ...

Ron Jeffries

ronjeffries.com

Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[bruno...@cegeka.com]

As it is an introduction, the audience can vary strongly and we always tune the training to the audience.

If the training is given to a transformation journey customer, we try to mix-match the audience as much as possible (Developers, Business, HR, Sales, C-level), making sure the fundamental idea of Flow over departments is in there from day 1.

If the training is given internally (we are part of a larger IT-partner company), the audience is mostly Developers & Customer Proxy's (aka business analysts).

Op vrijdag 10 augustus 2018 19:21:21 UTC+2 schreef Ron Jeffries:

[Pierre Neis]

In a one day Agile training, the most important is to focus on team: behaviour, dynamics.

Considering the organization with are their levels as a team influences behaviour. Based on that, you can built on the top.

Pierre E. NEIS senior agile coach agile² GmbH m: +49 (0)160 998 724 49 a: Gaisbergstraße 4 69115 Heidelberg - Germany w: www.agilesqr.com

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ron Jeffries]

On Aug 13, 2018, at 3:26 AM, bruno...@cegeka.com wrote:

As it is an introduction, the audience can vary strongly and we always tune the training to the audience.

To me, "real" Agile is important, and my primary interest is in the good effects that real Agile has on the development team, not just advantages to the company. That might make my preferred presentation unpalatable to a company trying to get transformation business.

(I am also famously skeptical about "transformation". It sells well, and will continue to sell well for a while, and it can provide benefits to the organization. I do not think it is usually good for the people, and that troubles me. Many people disagree with my views there.)

To me, the essence of Agile is of course the Manifesto, so I'd riff at least on the values and what they really mean. I might not hit all the principles, as that would make for a boring talk, but I'd probably refer to some of them in passing, while presenting a different arc.

I would certainly point out that working software comes up about 61 times in the Manifesto and that's because it's far more important than most people seem to realize.

I'd focus on the iterative cycle of considering a small part of the problem, producing a real working solution in a week or two, and then using that growing solution to guide thinking on what to do next and how to improve it. I'd emphasize that the most famous framework demands a running tested increment every Sprint, and admonish them that they need to learn how to do that, because it's critical to Agile really working.

Some, of course, don't know this, or disagree with it. This is the biggest, most pernicious, mistake in hawking Agile. Since this is my answer, I get to focus on what's important.

Did I mention that the Manifesto mentions working software about 531 times? Well, it does and that's for a reason.

I'd of course outline how things would work, according to the one or two framework options I'd be selling. Sprints/iterations, or a more  continuous flow kanban-like thing. I'd want to focus on cross-functional, self-organizing teams, and on pushing real product decision making down into the development teams.

A lot of the session, even in an hour, I'd probably dedicate to questions.

And, with only an hour, if it's important, I'd want to have already talked with some of the key participants and built up a real sense of their particular understanding and interests, since we only have an hour and want to hit what they need to hear.

Ron Jeffries

ronjeffries.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Pierre Neis]

I use to try a clean question: what kind of agile is your agile? And collect the inputs and build on it.

This question comes before any explanation.

Pierre E. NEIS senior agile coach agile² GmbH m: +49 (0)160 998 724 49

a: Wilhelmstraße 4  69115 Heidelberg - Germany

w: www.agilesqr.com

[Jon Kern]

Off the top of my head…

#1) Ensure the purpose is clear. 

• What problem are we trying to solve by disrupting EVERYTHING and going agile? 
• What do we hope to achieve? Can we measure it?
• Better yet: Have the business champion/president/ceo state emphatically their support for the move to agile.

#2) It’s a People problem, not a process or technology problem

• Ensure that everybody understands the need for open and honest communication to succeed
• The best way to give agile a bad name is to force it down people’s throats

#3) Use your brain

• You might start out by rote mimicking a process to give it a chance and learn by doing what others have dubbed as successful
• But you better not abdicate thinking for yourself
• Best not dogmatically follow a process and do stupid things — like cut people off at the 15-minute mark when the standup must be done (or else!!!)

#4) Scrum is a meta process — can be applied to any project

• Just because you do Scrum, doth not agile make
• Don’t be fooled with the Scrum tool
• Scrum is not even needed
• Hell, building software is simply a prioritized to-do list, planned just enough ahead of time to suit your needs

#5) Agile is a state of mind and contextual

• There is no standard practice or process, making it hard and not fun for those who love following processes with clear input and output
• Agile is about doing what is best for the business
• You are not allowed to cherry pick and do silly things like forego documentation and write untested shitty code
• You are allowed to say the tests (that provide complete code coverage) and well-written code are the documentation (for the code)
• You are allowed to write untested crappy code if you are doing experimentation. Just do not let it come into the repository main develop branch!
• If you think the same agile applies to an application that is highly regulated or can kill people as a simple app for tracking fantasy stats for your friends, then you are missing how much the context matters

Now you may start to reveal the 4 measly bullets that took the world by storm… These bullets reflect the essence of human behavior as pertains to software development. They are as valid now as they were when we came up with them. And they will be valid 100 years from now. (Much like the core tenets of Declaration of Independence that got to the core of man’s governance over man. If I might be so humble to draw such a comparison across domains and centuries.)

And you must point out the ambiguity we purposefully left in the left vs right preference… It is key, IMHO.

Agile process and practices are all about reducing the gap in time between taking an action and getting feedback. Writing code, test feedback. Shipping always, feature feedback from users. And so on.

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

github: https://github.com/JonKernPA

[Glenn Waters]

+lots to what Jon said.

Said another way: How can we ensure that we are building the right thing? That can perhaps lead to discussions around:

• Are we deploying/showing running tested software regularly?
• Do we have dedicated teams?
• What's our WiP like? Does that serve us?
• Are we building the thing right?
• Can people collaborate easily?
• Is there safety to say/do what is needed?
• Are we using technical practices that serve us well? 
• Do we understand what our customer/client needs?
• Do we try and improve how we work regularly?
• Are we empowering our people?

Glenn

[Ron Jeffries]

I'm not at all sure why most of those topics go under are we building the right thing ...

On Aug 13, 2018, at 4:39 PM, Glenn Waters <gwwa...@gmail.com> wrote:

Said another way: How can we ensure that we are building the right thing? That can perhaps lead to discussions around:

• Are we deploying/showing running tested software regularly?
• Do we have dedicated teams?
• What's our WiP like? Does that serve us?
• Are we building the thing right?
• Can people collaborate easily?
• Is there safety to say/do what is needed?
• Are we using technical practices that serve us well? 
• Do we understand what our customer/client needs?
• Do we try and improve how we work regularly?
• Are we empowering our people?

Ron Jeffries

ronjeffries.com

It's true hard work never killed anybody, but I figure, why take the chance?

-- Ronald Reagan

[James Grenning]

I'd suggest starting with "what problem(s) are you trying to solve?"

[J. B. Rainsberger]

I ask a similar question: "What problem(s) do you expect 'Agile' would help you solve?" I use this to try to learn about the client in a way similar to Pierre's Clean Language version of the question "What kind of 'Agile' is your 'Agile'?" We can then spend time discussing everyone's needs and expectations, and then with whatever time remains in the way, we can discuss values, principles, practices, that kind of thing.

--

J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca ::
blog.thecodewhisperer.com