A gentleman named Teo Tayobobayo on Google+ prompted me to write this comment to a post by John Fiore. I’m positing it here because I think it’s of interest to a wider audience.

As a fan of Approaches in Fate Accelerated Edition, I wanted to speak to your [Teo’s] statement above: “I am saying that when someone is hacking a computer I have a hard time deciding which Approach is most appropriate (is that Sneaky, Clever, Flashy, Forceful… it seems like it could be any of the above) whereas is it pretty easy for me to decide that it’s a matter of Crafting.”

I like Approaches because they increase the chances that players will attempt something creative. With skills, I’ve heard player conversations like “I don’t have Crafting, do you?” and self-censoring their character’s behavior, whereas I hear fewer conversations like that with Approaches.

As GM, I don’t choose which Approaches are more appropriate beforehand (though I will often form an opinion as I design a situation). Instead, I guide the player in choosing. I developed this approach (no pun intended) from narrating Dungeon World. Extending the Approaches example from FAE page 18, let’s say there’s a character named Fiona trying to creep across a dark room. The verb creep seems to make the Approach choice clear. Or does it?

When an Approach choice strikes me as odd, I’ll ask questions like “what is Fiona trying to accomplish?”, “what happens if Fiona fails?”, and “what does Fiona gain from being Forceful as she creeps across the dark room?” This can often lead to reframing the question and more interesting stakes. Consider:

• Can Fiona creep across the dark room Carefully, without leaving a trace?
• Can Fiona creep across the dark room Cleverly, without setting off the trap?
• Can Fiona creep across the dark room Flashily, taking unnecessary risks and impressing her skeptical thief lord patron?
• Can Fiona creep across the dark room Forcefully, showing a commanding presence and emboldening the rest of the party who’s wary of traps?
• Can Fiona creep across the dark room Quickly, before the patrol comes back?
• Can Fiona creep across the dark room Sneakily, without making a sound?

I realize some of these examples are more contrived that others, but I hope the point is clear. Approaches lend themselves better to this dialogue than Skills do, in my opinion.

Inspired by a gentleman named Ulric on Google+ who is writing a Doctor Who setting for Fate Core, I thought I’d have a go at it using Fate Accelerated Edition. I ended up writing more than a post’s worth of stuff, so I’m providing a link to the document in HTML format (Editor’s note: defunct). Let me know what you think.

So far, I have a write-up for the Regeneration stunt and three incarnations of the Doctor as character samples. I also have the TARDIS as an Extra. Since then, I’ve been looking through the Fate System Toolkit and was excited to see a couple of nods to Doctor Who. I am close to ready to play-test an adventure using this adaptation.

This week, I attended a week-long agile training class provided by Rally. Overall, I thought the experience was positive. The company brought all of the development and product departments together for an agile overview. While many of us felt the material was remedial, there was clear value in having the same material presented to the entire software development community at once. Through exercises like the ball point game, we learned the mantra of inspect and adapt.

Some of us remained for the scrum master and product owner training. I applaud the leadership team for insisting that prospective scrum masters attend PO training, and vice versa. Since the two roles work together to fuel an agile delivery team, they wanted us to gain an appreciation and understanding of the other role. I recommend this approach.

There were portions of the training I really enjoyed. For example, many of us got some value from the facilitation techniques they introduced – I hope the company follows up with in-depth training. And I enjoyed the exercise of dreaming up a mobile phone application, creating personas, and developing and refining the product’s epics, features and stories. Our team came up with Mahalo, the water sports equipment rental application. Our stories read, “As a surfer dude or chick…” and our error messages inevitably started with “Bummer, dude….” Entertaining and educational.

While I am a certified scrum master, I haven’t had as much exposure to the product owner material. On my first team at the company, I had trouble mentoring our product owner in fulfilling his role. Neither of us had formal PO training, and the company’s expectations of him were different than the normal scrum expectations of the role. For example, the company’s title for this role has the word “manager” in it, and it led him to try to manage the delivery team. The resulting churn was frustrating for everyone.

I happened to sit next to him during the product owner training, and a part of me wishes I could be back on that team. I think he took the training to heart and I think the team will benefit from clear role delineation and expectations. I’m sure similar insights happened throughout the room, and that will pay strong dividends going forward. Now having been through this training, I think if I found myself in a similar situation, I have a better idea how to approach helping another PO. I certainly gained an appreciation for the challenges of the role during James Shore’s Offing the Offsite Customer simulation game.

On the other side of the coin, I was frustrated at times by the training. For me, the training did not have much depth in any area. Many of my colleagues and I commiserated that just when something got interesting, we had to move on to keep pace with the agenda. A glaring example: our facilitator Chris showed a video of Simon Sinek on Start with Why: How Great Leaders Inspire Actionhttp://www.youtube.com/watch?v=u4ZoJKF_VuA), but ironically, he stopped the video about 5 minutes in right when Simon started to talk about why to start with why. Despite the groans in the room and calls to play it through, we had to move on.

Wanting more, I was encouraged to hear that the company plans to have a coaching engagement. I think that having agile coaches come in, observe our process, and help up fine-tune it would be a tremendous value. Imagine my dismay when I later heard that coaching is seen as a two-week engagement for a couple of troubled teams. I wish Rally had spent time talking about how to evolve your agile practice to fit your business. It’s like David Snowden of Cynefin fame says, “practice without sound theory will not scale”.

It also seemed like the leadership team was hoping that the training would validate the company’s delivery process. They had a committee create a new working agreement between development and product, and unveiled it just prior to the training. Judging from the number of questions and concerns that were raised, it seems that there are a number of crucial conversations needed before we can implement it as written in earnest. However, I should also add that the parts of the executive team did stay for the whole training and they repeatedly stated an interest in candid and frequent feedback, so perhaps this is a communication issue rather than a philosophical one.

Having lead a number of teams in my time, I chuckle at the idea of using the same working agreement for all of them. They had different personalities, different types of work (greenfield app development versus customer support), and different levels of agile experience. For some, by the book Scrum was the most appropriate approach. For others, a lean workflow organized through Kanban worked wonders. Furthermore, the approach changed over time. By forcing all the teams to use vanilla scrum and requiring company-wide adoption of any changes, I am concerned that the company capped its agile skills by teaching to the lowest common denominator. This approach doesn’t work well in our American school systems, and I doubt it will be successful here.

Case in point, we spent a frustrating two hours trying to develop a standard user story template in Rally. I question the value of the exercise: of the agile adoption challenges the company faces, consistent user story formatting would not have been my top choice, and having 50+ people collaborate on writing a comprehensive template was wasteful. My main takeaway was that teams were using existing fields to combat shortcomings in Rally’s product, whether those are because the features don’t exist or whether they are hard to discover. For example, it seems many teams put the feature ID in the story title so that when they export story data, they can tie it back to a feature. To me, this is a Rally feature request for either more robust reporting or navigation capability – a request that won’t be solved with a user story template.

I wish the company’s communication emphasized a unified desire and approach to discovering the best process for the business, rather than an emphasis on standardizing on a common implementation of agile at a team level. I worry that elements of the process will get codified and fixed. As Nick Oostvogels points out, standardization in agile teams, “standards need to be alive and constantly change for the better”. It’s the principle of inspect and adapt, applied to the delivery process. I hope the company will take that principle to heart.

I’m back from my honeymoon, and the conference has posted pictures from the event. This is me giving my presentation.

After giving my talk at MHA 2013, I wanted to explore some of the examples the group came up with. Today, let’s talk about the Object Pool design pattern. Here’s a link to the Object Pool pattern on SourceMaking, in case you want to read up on the pattern before diving into this article.

In software, it’s more common that an object or container can create whatever dependencies it needs. In real life, this is a more common design pattern, because there are many situations that fit the criteria for considering it:

• you have a finite set of items
• each client needs a subset of those items
• the items are too expensive for everyone to have one of their own
• they can be re-used

To implement this pattern, you need three components:

• a reusable resource
• a pool that holds and releases the resources
• a number of clients, who consume the items

In the Object Pool pattern, the resource pool has some responsibilities:

• add a resource
• remove a resource
• set resource limit

Straightforward Examples

In these cases, it seems evident to me how the pool can manage the resources. The following examples bear closer examination.

Bank Loan

Resource: lending money
Pool: the bank’s lending pool
Client: people wanting a loan

A bank loan is different from the other examples, in that in a sense, the bank can’t produce more money. it can, however, limit the amount of money it loans out to clients. It can adjust that amount to fulfill the contract for being a resource pool.

Technical Debt, team’s capacity

Resource: work capacity
Pool: gap between ideal software and working software
Client: features

Technical debt is a tougher example. How do you measure technical debt? One imperfect way, perhaps, is in man-hours of effort. Once you find a currency for technical debt, you can see that it is analogous to the bank loan example. Think of the team producing software as a software factory. You can add extra work capacity to the factory by taking on technical debt – that is, adding it to the system. You can release technical debt by addressing the shortcomings of the software, though it reduces work capacity. And technical debt is limited in nature; too much technical debt can destabilize the software to the point where it is too fragile to handle normal operational conditions. Smart teams place a technical debt limit lower than the degenerate level I just described.

The team’s capacity can be thought of the same way. A team’s capacity is regulated in part by how much time is allocated to a project. This is why many teams who use ideal man hours to measure capacity do not use 8 hours a day. There are inevitably interruptions, meetings chief among them. This reduces the figure to maybe 6 ideal hours a day of productive work. Capacity can be added through people or more work time, and can be reduced through the same means. It’s easy to see how capacity can be limited by taking the example to extremes.

For example, if you reduce the capacity to absurd levels, the waste inherent in spinning up – that is, figuring out how to begin the next unit of work – will consume all of the team’s available bandwidth. On projects where the code is not touched for long periods, this effect is very pronounced.

Scrum coach, friends of the team, consulting firm

Resource: people with expertise
Pool: a group of those people
Client: teams needing their expertise

Here, the currency is expertise. Companies can add and remove coaches through hiring, firing and of course transition to other job responsibilities. They limit the number of coaches through the number of positions they maintain. The same approach can be used with database administrators or user experience designers.

Consulting firms help companies staff using the same paradigm. Unlike the other examples, consultants don’t work for the same company as the teams who need them. Said in reserve, this pattern doesn’t require the clients to own access to the resource. Although, if you look at the early examples, it’s clear that in the library and bowling shoes cases, the patrons don’t own the shoes or the books.

Farm league

Resource: minor league players
Pool: the teams comprising the minor leagues
Client: major league teams

This is perhaps my favorite example, because I hadn’t thought of farm leagues this way. Players are added to farm teams though the draft. They are released through training and though players being “called up” to the majors, as well as through players being released from the farm teams themselves. There are a limited number of teams with set numbers of players on the roster, so there is an inherent limit to the system.

You can extend this line of reasoning to any apprenticeship program. And, taking the analogy further, perhaps you can think of a high school or university in the same way.

Being the first write-up, please let me know what you like about this write-up, as well as ideas to make it more interesting or useful. For example, would a diagram be helpful?