XPost: comp.programming, comp.lang.c, comp.lang.clipper
XPost: alt.comp.lang.ada

What a Coding Dojo taught me about agile
Full story: [url]https://opensource.com/article/18/10/what-coding-dojo-taught-me-about-agile[/url]
[size=2]It's essential to value individuals and interactions over
processes and tools. Here's why.[/size]

In their article, What is agile?, Jen Krieger, Daniel Oh, and Matt
Takane discuss what we at Red Hat consider the most important sentence
of the Agile Manifesto:

“We are uncovering better ways of developing software by doing it
and helping others do it.”

I like this sentence because it helps to understand why we could apply “agile” outside of software development. We could replace “developing software” in that sentence with something like “cooking,” and it would still give us a good idea of the mindset of people who engage in “agile cooking.”

More DevOps resources

The ultimate DevOps hiring guide
What is DevOps?
The open source guide to DevOps monitoring tools
10 must-read DevOps resources
Free eBook: DevOps with OpenShift

Of course, we often associate “agile” with specific practices. Let’s
take the example of two agile practices that were used together during a
Coding Dojo event. A Coding Dojo is a great way of uncovering better
ways of developing… I’ll stop there; you know the rest of the sentence
by now. A Coding Dojo is a great way to get better at something by
practicing with others in a safe and controlled environment. The
practices I uncovered that day were test-driven development and pair programming:

Test-driven development, or TDD, is a process in which a developer
starts by writing an automated test for a function, then writes the code
that will make the test pass.

Pair programming is when two coders work together using one computer.

[b]The Coding Dojo experience[/b]

.... more .....

The interaction between the two coders is the kind of magic we all love
to see. That's because contributors are not submitting a patch hoping
for a fast review; they have the review in real time. And because they
are progressing in small steps, explaining what they are doing, it is
easy for everyone to stay connected, whether you are in the audience or
the second coder in the pair.

Why do we consider pair programming and TDD agile practices? Because
they are designed to foster strong interactions between the individual
members of the team. These interactions help them express their best in
the code they produce.

This brings us to the second sentence of the Agile Manifesto:

“Through this work, we have come to value: Individuals and
interactions over processes and tools.”

You can, of course, have processes and tools. But those processes and
tools should foster the expression of individuals and their
interactions. The latter has more value than the former.

So the next time you are engaged in a conversation about tools or
processes, ask yourself (and others): Are we bringing a tool or a
process that will grow individuals and interactions?

Answering yes to that question shows you the agile way.


--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«!
½Ð¦Ò¼{ºî´© (CSSA): http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)