]]>
]]>
]]>
http://www.walyou.com/blog/2010/03/17/hornet-gyro-superbike/
]]>
Read more about it at Fast Company.
]]>
The senselessness of crunch-based production, and its human costs, have been a passion for many years. As fate would have it, a handful of opportunities have come in my career (at Spark Unlimited, Midway Austin, and Heatwave Interactive) to experiment with some solutions, and to unearth what I believe to be the root cause of crunch: premature production.
Anyways, please click through and have a read. If anyone out there has alternative or opposing thoughts, I'd love to hear them.
Article -- A Closer Look At Crunch
]]>
"A Tribute to the Madness of Beethoven"
What are you still doing here? Go there.
]]>
An excellent piece by Ash Maurya on achieving Flow in a startup environment. Flow is a concept of Lean Development.
Some quotes:
"Of all resources, there is no resource more valuable than time. Time is more valuable than money. While money can fluctuate up or down, time only moves in one direction – down."
"The cost of context switching is low (and expected) in a Manager’s schedule. It is high (and a productivity killer) in a Maker’s schedule."
"Unscripted conversations are the best way for learning about unscripted problems."
http://www.ashmaurya.com/2009/12/achieving-flow-in-a-lean-startup/
Found on the Lessons Learned blog by Eric Ries.
]]>
A few times a year, the opportunity arises to introduce Agile production methodologies to new people, and occasionally help teams make the conversion. Each time is exciting and rewarding in its own way; every team is unique, each with its own strengths, its own ways of working, and reasons for entertaining a switch to a new production methodology.
Yet, despite the diversity of these teams, their questions tend to follow similar patterns. How is it different? How does it work, day-to-day? Will it fix all of our problems? And team members’ expectations run the gamut -- some passionately support adopting an Agile methodology, such as Scrum (although sometimes with unrealistic expectations), and some actively resist (sometimes close-minded to constructive change).
Skeptic wary of the True BelieverMost often in my experience, the more seasoned, process-minded sorts who are the most skeptical (*cough*…engineers…*cough*). The word “Scrum” immediately raises defenses, the cult-detecting alarm bells start jangling in their heads, and they all but make the sign of the cross and hiss.
On the flip side, those most dissatisfied with the status quo – due to internal politics, dissatisfaction with established reporting chains, or chronic frustration with unreasonable expectations (*cough*…creatives…*cough*) – are desperate and willing to try anything, and dammit, this “Scrum” stuff could be the answer!
These days, many teams have experimented with Scrum, and I often hear horror stories (usually from the people who were skeptical in the first place) about how “it didn’t work” for them. After some gentle probing, it often turns out to be the same reason, regardless of team: the basic Scrum roles weren’t truly adopted.
One of the foundational components to Scrum is the role structure. The structure is very simple. There are only three roles: The Scrum Team, The Scrum Master, and the Product Owner. The team does the work. The Scrum Master(s) facilitate the process. And the Product Owner is the lead of the project (or product).
The challenge for any team serious enough to entertain a change of this magnitude is this: How will it adjust its legacy role structure to map to Scrum’s role structure?
Much of the time, that adjustment simply doesn’t happen. The team takes on Scrum in name, but not in practice.
Most specifically, it tends to be a project’s leaders (Lead-level and above) which have the hardest time adjusting, and tend to resist Scrum’s decision-making structure. The prescribed role of the Product Owner – a single person (or as I’ve seen, sometimes two or three) who gets final say on prioritizing the work – proves too big a threat. The Leads, Directors, Department Heads, and other lieutenants and stakeholders fear that their roles will diminish (although this need not be the case).
And it’s not just those who are threatened by the Product Owner – often the person selected to be the Product Owner fundamentally misunderstands the role itself, failing to embrace its authorities and responsibilities, and continues to reinforce the legacy role structure, inadvertently sabotaging the process.
In the end, the methodology frequently gets blamed by its would-be adopters, and teams revert to less threatening methodologies.
So I implore you, dear reader: If your team is considering Scrum (or any form of Agile), but is unwilling to embrace the fundamentals to ensure its success -- then move along. It’s not worth the time and money (a significant investment - 3+ full sprints under a properly implemented conversion, which can be 2-3 months of burn).
But I also entreat you: If your team leadership is sufficiently mature to admit when their methodology isn’t performing well enough – to the extent that they’re open to trying on some new hats and giving a different methodology an honest shot – you’re in for nothing short of a significant quality of life improvement, and a distinct development advantage.
-------
For more information on Agile methodologies, check out the book list.
Were you on a team that tried a production approach that didn’t work? Tell us about it below!
3D packages are becoming more specialized and diverse -- and exciting. Because after all, 3D artists don't want to push verts all day.
The new section can be found here. Some teasers below.
The new section can be found here.