Subscribe: James Shore
http://www.jamesshore.com/index.rss
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
agile engineering  agile fluency  agile  fluency  game  james shore  james  model  shore news  shore  talk  teams  work  workshop 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: James Shore

James Shore



The Art of Agile



Copyright: Copyright 2000-2006, James Shore
 



Agile Fluency Model Overview Video

Wed, 10 May 2017 00:02:00 PST

10 May 2017 James Shore/In-the-News

The Agile Fluency™ Project has put out a new video overview of the Agile Fluency Model. Diana Larsen provided the words and I did the animation. It's on YouTube, so it's easy to share with others and use in your presentations.

width="560" height="315" src="https://www.youtube.com/embed/69dsU-_EEzM" frameborder="0" allowfullscreen>

I'm particularly proud of how this one came out. Here's the direct link.




ScrumMaster Toolbox Podcast on Agile Fluency Model

Wed, 10 May 2017 00:01:00 PST

10 May 2017 James Shore/In-the-News

Diana Larsen and I were interviewed on the Scrum Master Toolbox Podcast earlier this year. We shared our latest thoughts on the Agile Fluency™ Model, including why it's different from a maturity model (and where the idea of "maturity" might fit into the model), our "bus zone" metaphor, and how to use it in your work.

Listen to it here.




A Nifty Workshop Technique

Wed, 05 Apr 2017 00:00:00 PST

05 Apr 2017 James Shore/Blog

It's hard to be completely original. But I have a little trick for workshops that I've never seen others do, and participants love it.

It's pretty simple: instead of passing out slide booklets, provide nice notebooks and pass out stickers. Specifically, something like Moleskine Cahiers and 3-1/3" x 4" printable labels.

(image)

I love passing out notebooks because they give participants the opportunity to actively listen by taking notes. (And, in my experience, most do.) Providing notebooks at the start of a workshop reinforces the message that participants need to take responsibility for their own learning. And, notebooks are just physically nicer and more cozy than slide packets... even the good ones.

The main problem with notebooks is that they force participants to copy down material. By printing important concepts on stickers, participants can literally cut and paste a reference directly into their notes. It's the best of both worlds.

There is a downside to this technique: rather than just printing out your slides, your stickers have to be custom-designed references. It's more work, but I find that it also results in better materials. Worth it.

People who've been to my workshops keeping asking me if they can steal the technique. I asked them to wait until I documented my one original workshop idea. Now I have. If you use this idea, I'd appreciate credit. Other than that, share and enjoy. :-)

(image)




Final Details for Agile Fluency Coaching Workshop

Tue, 21 Mar 2017 00:00:00 PST

21 Mar 2017 James Shore/Blog

Our Agile Fluency™ Game coaching workshop is coming up fast! Signups close on March 28th. Don't wait!

We've been hard at work finalizing everything for the workshop. We hired Eric Wahlquist to do the graphic design and he did a great job.

(image)

Diana Larsen and I have also finalized the agenda for the workshop. It's so much more than just the game. The workshop is really a series of mini-workshops that you can use to coach your teams. Check 'em out:

  1. The Agile Fluency Game: Discover interrelationships between practices and explore the tradeoffs between learning and delivery
  2. Your Path through the Agile Fluency Model: Understand fluency zone tradeoffs and choose your teams' targets
  3. Zone Zoom: Understand how practices enable different kinds of fluency
  4. Trading Cards: Explore tradeoffs between practices
  5. Up for Adoption: See how practices depend on each other and which ones your teams could adopt
  6. Fluency Timeline: Understand the effort and time required for various practices
  7. Perfect Your Agile Adoption: Decide which practices are best for your teams and how to adopt them

These are all hands-on, experiential workshops that you'll learn how to conduct with your own teams. I think they're fantastic. You can sign up here.




The Agile Fluency Game: Now Available!

Wed, 01 Mar 2017 00:00:00 PST

01 Mar 2017 James Shore/Blog

Five years ago, Arlo Belshee and I created a game about agile adoption. The ideas in that game influenced the Agile Fluency™ Model, Arlo's Agile Engineering Fluency map, and the Agile Fluency Diagnostic. We always intended to publish the game more widely, but the time and money required to do professional publishing job was just too much.

Until now.

I am very proud to announce that, in collaboration with the Agile Fluency Project, the game I've spent the last five years play-testing and revising is finally available! I'm conducting a special workshop with Diana Larsen that's packed full of useful exercises to improve your Agile coaching and training. Every participant will get a professional-produced box set of the game to take home.

Every time we've run the Agile Fluency Game, players have asked to get their own copy. Now it's finally available.

Sign up and learn more here.




Evolution of Agile

Wed, 31 Aug 2016 00:05:00 PST

31 Aug 2016 James Shore/In-the-News

I guest-starred on the Ruby Rogues podcast in August 2016. We had a wide-ranging talk discussing how Agile has changed over time, evolutionary design, large-scale Agile, and more. It's one of my favorite podcast appearances to date. Well worth the listen.

Listen to it here.



Two Talks on Scaling Agile

Wed, 31 Aug 2016 00:04:00 PST

31 Aug 2016 James Shore/In-the-News

I've been doing a lot of work with multi-team development projects recently, and this has resulted in two good talks on large-scale Agile.

Scaling Beyond the Enterprise

My first talk was a keynote for Agile India in March 2016. It provides a good overview of the issues that come up, some of the solutions, and discusses my approach is different from existing approaches to scaling.

Scaling Beyond the Enterprise

The brilliance of early Agile methods was their non-conformity. They rejected conventional wisdom about how software should be created and substituted a new reality: one where collaboration, adaptation, and continuous improvement were more important than rigid processes and plans. At first, many people rejected these innovations, but Agile stood the test of time. Now it's won the day.

When people talk about scaling Agile, they forget those insurrectionary roots. They focus on what's palatable to the "enterprise:" how to make Agile safe, non-threatening, and acceptable--how to make it more conventional and conformist. In doing so, they risk losing the innovations that make Agile work so well.

What if we stopped worrying about what's safe and acceptable? What if we went back to those innovative roots? What would Agile look like if we scaled beyond the enterprise?

Come find out.

width="560" height="315" src="https://www.youtube.com/embed/bjbuTk7KVFA" frameborder="0" allowfullscreen>

Rethinking Scaling

At the I T.A.K.E. conference in Romania, in May 2016, I keynoted on this topic again. This was an audience of developers, so I took a deeper look at the architectural and team structure considerations. There's a bit of overlap, but it goes into more detail with more examples. I'm particularly pleased with how this talk came out: it's covers a very solid list of things to think about as your company grows.

Rethinking Scaling

That feeling of a successful startup. A handful of people in a room, getting shi...ny things done. Everybody working together, all cylinders firing. It's intoxicating.

That feeling of a great XP team. A cross-functional team, all in a room, getting shi...pping done. Everybody working together, sharing responsibility, creating great code. It's impossible to forget.

But what do you do when the startup IPOs, and the 12-person company is now a 1000-person behemoth? What do you do when the XP team grows, and you have 100 people working on a product, not ten? How do you keep those great small-team dynamics in a big organization?

When people talk about scaling Agile, they focus on what's palatable to the "enterprise:" how to make Agile safe, non-threatening, and acceptable. But what if we aren't in that kind of company? What if we know what it's like to be great, but we're too big to do it the way we used to?

Let's set aside the brand names, consulting companies, and enterprise certifications. Let's look at the possibilities of large-scale Agile at its best.

width="560" height="315" src="https://www.youtube.com/embed/VOMKAa_tmQ0" frameborder="0" allowfullscreen>



Estimates or No Estimates?

Wed, 31 Aug 2016 00:03:00 PST

31 Aug 2016 James Shore/In-the-News

The Agile community has been arguing about whether estimates are a good idea or not for a while now. In this talk at Øredev in November 2015, I think I did a pretty good job of threading the needle. I talk about how and when to estimate, and why you might not want to.

Estimates or No Estimates?

There's a debate raging in the Agile world: should we estimate, or not? Lost in the noise are more important questions: When should we estimate, and why? When should we not estimate, and why not?

As with so many Agile questions, the answer to "should we estimate?" isn't a clear-cut "yes" or "no." Instead, the answer depends on what your team is capable of, what your organization needs, and how to best balance the two.

We'll take a deep look at how estimates work, why they work, and when and why to discard them. Along the way, we'll encounter surprising insights about the nature of Agile development and the teams that use it.

src="https://player.vimeo.com/video/145049619" width="640" height="360" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

ESTIMATES OR NO ESTIMATES? from Øredev Conference on Vimeo.




Agile Engineering for the Web

Wed, 31 Aug 2016 00:02:00 PST

31 Aug 2016 James Shore/In-the-News

I spoke on Agile engineering at Øredev in November 2015. I'm particularly proud of how well this talk came out--it's livecoding, which can be hard to do well, and it does a great job of showing how to test JavaScript and CSS. It's basically a summary of what I've learned from my Let's Code JavaScript screencast.

Agile Engineering for the Web

Test-driven development, refactoring, evolutionary design… these Agile engineering techniques have long been established for back-end code. But what about the front-end? For too many teams, it's dismissed with a "JavaScript sucks!" and unreliable, brittle code.

In this session, we look at what it takes to bring the best of Agile development to front-end code. Test-drive your JavaScript and refactor your CSS.

src="https://player.vimeo.com/video/144642399" width="640" height="360" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

AGILE ENGINEERING FOR THE WEB from Øredev Conference on Vimeo.




2015 Sydney Keynote

Wed, 31 Aug 2016 00:01:00 PST

31 Aug 2016 James Shore/In-the-News

I keynoted at Agile Australia in June 2015 and InfoQ recorded it. If you know somebody who's doing "Agile in name only," they should watch this video. Here's the blurb:

The Reward

For an approach that emphasizes simplicity, success with Agile is surprisingly difficult. Some teams see amazing results. They're able to respond to changing needs, deliver new releases every day, and do so with nearly zero defects. Other teams complain that Agile makes things worse, not better. They get less done and spend more time in pointless meetings.

What is about Agile that creates such different experiences? Let's take a step back and look at what makes Agile work. What's the point of these Sprints, stories, Scrums, and other practices? What leads to success and what leads to struggle? It's time for a frank discussion about what it takes to succeed with Agile.

See the presentation and transcript here.