I attended Ken’s ScrumMaster (tm) course over the last two days. Possibly more on that later, but for not I want to focus on something entirely different. People are just very incredibly decent when it comes right down to it.
Ken has an absolution jar in the center of the room to catch the $1 owed for being late back to your table or for cussing in the course. Each day a charity is chosen that has a connection to somebody in the room for the money to go to afterward. On Monday, I mentioned that I ran Dan Shi Martial Arts club, and it was selected as Monday’s charity. By the end of the day the jar held $21, and I took $20 of it to deposit as an anonymous donation. Awesome idea, and thank you everybody!
Tuesday morning I thanked everybody during the morning agenda for sharing their sins with the needy, and commented that they’d sponsored a single student for a single month, which is hugely appreciated. At some point during the day, people must have talked it around, because around 3pm Ken tapped me on the shoulder and told me that the group had collectively decided to send Tuesday’s money Dan Shi’s way as well… THANK YOU!
Around 4:45 I straightened up the money because I was having problems putting my dollar in for being late back from break. I counted ~$30 at that point. At 5:15 I collected the money, and found EIGHTY THREE DOLLARS in the mug. Everybody, thank you! That is hugely significant to an unfunded organization, and we thank you very very much.
You have collectively allowed us to sponsor a child for almost half a year. Thank you. You are all awesome, and it just reminds again that no matter how much we may disagree, argue, or bicker professionally, every single individual is first and foremost a person doing the best they can do.
The problem
You have what Chris Matts calls an “Order Taker” as your business analyst. This individual is occasionally your only access to the people that actually understand what’s needed, yet they’ve been positioned as the gatekeepers of knowledge.
Consider this tactic
Combine “The 5 Why’s” and “Feature Injection” and see if you can deduce the real information that led to a specific requirement or change.
The basis
The thing is, the person the BA is talking to likely does Feature Injection, even if they don’t know they’re doing it. They’ve created their mental model (or “understanding”) of what problems this software they’ve asked for will solve. Something comes along and breaks the model (or “Doesn’t quite match what we’re doing”), and they change the model (or “submit a change request”).
If you look at the outputs of this (the delta, or the specific change), you’ll observe that they probably share a common theme or two. If you keep asking “why” on the changes, you’ll accomplish two things. You’ll be able to understand what sort of learning occurred, and the further “why’s” will either lead to better answers (less “telephone” effect) or more questions for the actual business owner. Second, you’ll probably frustrate the hell out of the order taking BA, and there’s a tiny chance they’ll learn to act differently.
Either way, you probably understand the intent of the changes better, which means you can do a better job providing value.
btw, please please please try and fix the organizational structure first, but if you can’t do so, then you can begin finding the right ways to work around the impediments.
In the process of debugging an issue with a sample web application, I was forced to learn a bit more about IIS7's management model, and I found some very valuable information.
The problem: the user my request was running as did not have ACL-level access to the .svc file for that web service.
My old solution: Try random accounts before giving up and just giving access to "Everyone" for the entire web tree. (Yes, bad, but it's a sample)
My hope: There is a way to find out via logs, console, etc what the actual user is based on the actual failure rather than looking at all security configurations and randomly trying the referenced accounts.
What I found:
Open IIS manager, click at the web site level, and choose "Failed Request Tracing Rules"
![clip_image001[5]](http://manicprogrammer.com/cs/blogs/willeke/clip_image0015_thumb_676428D8.png "clip_image001[5]")
On the right, choose "Edit Site Tracing…"
Check "Enable", and note the location of the log files (note, there are implications on production sites. I don't know what they are. Be warned.)
Now, click "Add…" on the right, and choose your settings:
When you finish, you'll see something like this:
At this point, you can go to your logs folder and see the XML results of any errors that match your filters:
Opening one of those applies a nice transform (freb.xsl, I assume), and we have our data:
Including my answer:
And lots of other cool information:
And a summary view:
Including some really useful information that I would usually try to get out of Fiddler2 because of the challenge in collecting it in some configurations:
The time has come to take another big step towards my dreams and move into the next phase of my career. Understanding how this move is a natural extension of my current position requires an understanding of where I have been in the past and an appreciation of the context of each of those positions. I can divide my life to this point into five major phases of learning and development: childhood, college, and career phases one through three. I spent my childhood learning about the world around me, about whom I am, and about what core values I hold. I do not believe these core values or understandings will ever truly change, meaning I will for better or worse be a small-town Midwestern guy for my entire life. I then studied for four years at Rose-Hulman Institute of Technology. I acquired a great deal of knowledge in my time there, but more importantly, I became aware of how to learn. I gained the perspectives that allow me to compare what I see at any given moment against my experiences, the experiences of others, a varied set of perspectives, and an extensive body of knowledge. This process granted me the ability to quickly and accurately categorize information and identify inconsistencies within that information.
Finally, I moved into my professional career. I invested seven years into SEP, Inc. on the north side of Indianapolis. I believe this time consisted of two different phases with a fuzzy boundary between them. First, I learned my craft. My first four years focused heavily on direct delivery of value as a developer. I observed leadership behaviors during this time, and I learned about more than technology, but my primary focus was becoming an expert developer and coder. Second, I began to make the first steps into technical leadership roles. I became aware of the value of learning techniques from outside my role, and later from outside my industry. I started studying and evaluating different approaches towards accomplishing software delivery. I took responsibility for the design, flow, and implementation of software projects. I explored the “rules” imposed by various regulatory frameworks, and became inspired by recognition of the essence of flow buried deep inside. I examined the structures of people and projects around me, better understanding their behaviors. In short, I became aware of the non-coding aspects of the software engineering industry. More importantly, I began reading a number of business and economics books, histories of capital and finance, current events in business and industry. I launched “Rediscovering the Obvious”.
After a time, the yearning to do something different took over, and I accepted an offer to try my hand at product development. My first short gig in that direction did not work out, but I learned a great deal and moved to my current role at Inkubook.com. I came in as a senior software developer, but James, then director of Inkubook, promoted me to a software architecture role a short while later. This time was incredibly exciting to me professionally. This opportunity allowed me to spend nearly two years deeply focused on product development in a role allowing me a great deal of input into every aspect of the product and the context in which we built it. The environment at Inkubook is incredibly empowering in a number of ways. The team’s leadership offers individuals a great deal of flexibility and empowerment in how they approach their work and development. My management has been incredibly supportive of my speaking engagements, allowing me to tell the story of Inkubook publicly and providing time in which to do so. They have supported the team’s desire to learn with a very steady book budget and a ready environment in which we discuss what we learn. The architects regularly exchange sources and ideas about any number of technology topics. Ideas are encouraged and respected regardless of who originates them, and each idea is given a chance to prove itself before a decision is made. I have not worked in any environment so supportive of learning, and the effects are visible in the obvious engagement shown by each of my peers. This passion to improve amplifies itself within the team, leading us to a team culture of continuous self-improvement by each member of the team.
Why am I leaving Inkubook? I can honestly say there is no place in Indianapolis I would rather write software, it is a great place to work and the people are incredible. However, I have long been very passionate about how people go about writing software and delivering systems. EMC has offered me a position allowing me a great deal of freedom in my personal life. I will share more about the nature of this position when I understand which aspects are confidential strategy and which are more public. However, I will happily share my excitement on what this means for my life. First, I will be spending a month in London getting to know my team and delivering on some initial contracts over there. Then, I will be free of geographical constraints with the single primary restriction of needing to be near an airport. This frees Marian, Elle, and I to explore the world and try living different places. Equally importantly, this nicely aligns my daytime responsibilities with my learning passions, making work feel less like work. Finally, I love to teach, and much of this role will be directly helping people learn in various forms. Overall, this feels like the next natural evolution of my career, and I look forward to embracing the opportunity.
I just discovered a function in Linq that will save me a bit of typing and allow me to better express myself.
For a long while, I've written this:
ColorWrapper x = combo.Items.Where( obj => obj is ColorWrapper ).Cast< ColorWrapper >().FirstOrDefault(cw => cw.Color == value);
Today, I realized that the framework designers were ahead of me, and provided OfType<T>, which does the same thing as follows;
ColorWrapper y = combo.Items.OfType<ColorWrapper>().FirstOrDefault(cw => cw.Color == value);
Lesson Learned: Pay more attention to ALL of the aspects offered by a new technology, they all have their appropriate uses.
Excerpted from the first draft of my experience report for leankanbanconference.com:
Somebody has an idea to add value. Somebody approves the idea has merit, requests that it be built. Somebody transforms the idea into a set of specific changes that need to be made to the application from a user’s perspective. Somebody identifies how those changes need to relate to the existing technical implementation. Somebody causes chose changes to occur to the system. Somebody confirms that those changes were indeed made. Finally, somebody agrees that the changes did indeed provide the desired value.
It may not stick, but for the moment the incredible level of generic writing has a purpose in the document.
Just a reminder of something that has bitten us more than once. If you need to copy an XML value from one data object to another, use this syntax:
if
( copiedPlacement != null )
{
currentPlacement.FormatXML = new XElement(copiedPlacement.FormatXML); // USUALLY CORRECT!
}
If you use the following, you're actually doing a by-reference copy of the XElement, and changes to one will impact the other. Very subtle source of bugs if you're not paying attention, and a real pain to find later.
if( copiedPlacement != null )
{
currentPlacement.FormatXML = copiedPlacement.FormatXML; // USUALLY WRONG!
}
A new program and pricing structure has been created for the Lean & Kanban Conference in Miami.
There is now a Lean Day and a Kanban Day, each with a single track. The idea behind the new program is that it allows everyone to be able to see all the presentations, as well as enabling people to only come for a single day. Additionally, there is currently an Early Bird rate until April 13th.
The new pricing is:
- Full Registration (May 6-8) for all 3 days is $700 (subsequently $800)
- Lean Day only (May 6), including evening reception, is $335
- Kanban Day only (May 7), is $295
I’m also pleased to be able to announce a couple of promotions for readers of this blog. Please email me (kjscotland-at-yahoo-dot-co-dot-uk) if you would like to register at these prices.
- A Super Early Bird rate of $550 for all 3 days.
- A Corporate rate, which includes 5 places for the price of 3, at the Super Early Bird rate of $550. (5 places for $1650).
[Thanks to Karl Scotland - I stole his post entirely]
We love LINQ! We have used it for a lot of things on our project, and it has helped us with hitting a lot of deadlines. Unfortunately, in one instance it's been burning us for a few months now, and we didn't know it. Look at the code sample below. I've renamed the classes and a bunch of other things that might be considered confidential, but the logic is identical. Can you spot the bug? Try to before you read on to see the fix.
public class MyService
{
protected DataContext db = new DataContext();
public IList<ContentElement> CopySomething(Guid targetContainerID, List<Guid> sourceElementIDs)
{
List<ContentElement> sourceElements = db.ContentElements.Where(ce => sourceElementIDs.Contains(ce.ContentElementID)).ToList();
IEnumerable<ContentElement> newElements = sourceElements.Select((se, position) =>
new ContentElement()
{
ContentElementID = Guid.NewGuid(),
ContainerID = targetContainerID,
ContentXML = se.ContentXML == null ? null : new XElement(se.ContentXML),
FormatXML = se.FormatXML == null ? null : new XElement(se.FormatXML),
IsCopied = true,
ImageSourceID = ImageSource.Copy
}
);
sourceElements.ForEach(ce => ce.IsCopied = true);
db.ContentElements.InsertAllOnSubmit(newElements);
db.SubmitChanges();
return newElements.ToList();
}
}
Did you find it? It took me a long time to realize what was going on. Here's the fixed version.
public class MyService
{
protected DataContext db = new DataContext();
public IList<ContentElement> CopySomething(Guid targetContainerID, List<Guid> sourceElementIDs)
{
List<ContentElement> sourceElements = db.ContentElements.Where(ce => sourceElementIDs.Contains(ce.ContentElementID)).ToList();
List<ContentElement> newElements = sourceElements.Select((se, position) =>
new ContentElement()
{
ContentElementID = Guid.NewGuid(),
ContainerID = targetContainerID,
ContentXML = se.ContentXML == null ? null : new XElement(se.ContentXML),
FormatXML = se.FormatXML == null ? null : new XElement(se.FormatXML),
IsCopied = true,
ImageSourceID = ImageSource.Copy
}
).ToList();
sourceElements.ForEach(ce => ce.IsCopied = true);
db.ContentElements.InsertAllOnSubmit(newElements);
db.SubmitChanges();
return newElements;
}
}
Do you know what was broken, and why adding a .ToList() fixed it? Go ahead, guess... leave a comment if you will.
It finally hit me when I put the following command into the immediate window: newElements.First().ContentElementID
I did this a second time for some reason, and realized that the value was DIFFERENT?
Why is this? Well, it turns out that before I added the .ToList() after the select statement (and changed it to a list), it was getting requeried each time I asked for it. It was a query, not a set of actual values, after all. Thus, the write to the database was getting one set of values, and the the return was getting another set of values. The side effect of this error was, unfortunately, being hidden on the client side until recent functionality exposed it. So it sat there merrily humming along producing inconsistent data for months, and never really hurt anybody. Amazing.
Earlier today, on Twitter
Me: Having issues with the positioning of continuous integration vs branching models lately. Absence of latent code pattern description, mostly.
Scott: What are the issues?
Me: Mostly around cross-team/large product situations where the need for selective feature disabling may arise from QA finding
Scott: Tell us more.
Me: This blog post
Continuous Integration
I've always viewed the concept of continuous integration (CI) as a very good thing. I relentlessly persue the reduction of batch sizes until it doesn't make sense due to the transaction costs. I believe strongly in individual (pair?) developer discipline. I believe less strongly in a strong unit testing library and TDD, but view it as "usually a great thing". I believe in flexible designs capable of handling varied changes in short durations. All the things that enable cross team CI are things I believe strongly in following, but I just don't quite agree that it should be taken all the way.
On the kanbandev group on Yahoo! groups, there's an incredible conversation going on between Brad Appleton and Bas Vodde between how large development teams can work using CI techniques, and the crux of the discussion briefly converged on the question: "Can you have large integrated teams without using a branching model?" For the purposes they are discussing, I would happily say "Yes". However, I'm running into a different reason for branching: Providing options to management.
CI vs. Options
A branching model allows our developers to practice CI against a branch specific to their current Minimal Marketable Feature (MMF). Due to our frequent (average ~1.5 per week) releases to production, we have determined that we never want to have a partial MMF in production. Given a work in progress (WIP) limit of two MMF's in dev and three MMF-equivalents [1] in SQA, we tend to do a production release whenever SQA approves one of their three slots. Our branching model allows us to do a good job testing the MMF on its branch because we update the branch from the main line on a regular basis and definitely before we push to the test environment. This allows a quick smoke test after we merge the branch back to main rather than a massive regression effort. This model allows our management to make a decision about individual MMF's quality and determine which ones should be pulled into SQA (and thus for production). However, if an MMF happens to have poor quality, it is almost always found while the MMF is still on the branch, allowing its bugs to be worked and brought up to an appropriate quality while other MMF's are able to continue. I think this is similar to the Release Train model, but rather than be on a time interval, it's pull-based off of the SQA's output queue.
Option source: Branching vs. Latent Code?
There are other ways of accomplishing the same goals. Specific features can be enabled or disabled through configuration properties at either build or runtime. This is _probably_ the better pattern for most situations. The situation I'm encountering with Inkubook is that many new featues are forced to touch huge swaths of the app (recent examples: Adding calendars (vertical), improving client performances (horizontal), modifying cloud usage (interface point)). My question becomes: Are there effective latent code patterns for board, multi-tier changes? Given the nature of our application, I'd rather not have the code compiled into the client, even if it's disabled by hiding a button or whatever... silverlight spy makes it all too easy to turn that button right back on. Disable things at the service layer? Do I write acceptance tests that ensure that other in-flight features are NOT accessible? That seems like waste. Seems better to know that the code just isn't there... the costs aren't bad if you're good at branching, but at the same time, flipping off a property seems better.
Internal Consensus
As you can tell, I don't really seem to have a full perspective on this yet. I'll let you know when I decide, but for now I'll recognize the value inherant in both approaches and wait for a reason to change my perspective.
[1] An "MMF-equivalent" is a nice tag to describe a batch of priority one bugs that have accumulated in the main line and are determined to be worth testing and releasing without waiting for the next MMF to be merged in and released.
(Rescheduled to) May 6th-8th
http://www.leankanbanconference.com/
I'll be speaking, as will many of the leading thinkers in the Lean and Kanban software movement. Definitely worth a look at the site, and I really hope to see many of you there!
The announcement from kanbandev:
The Kanban conference is happening and the registration site is open.
http://www.leankanbanconference.com/
The site is a little basic at the moment. David Laribee and I sat up
in the small hours and got to this minimum marketable feature state.
We'll both be offline for a few days over New Year. We'll make the
site look pretty and add some more features next week. For now you can
register.
We're giving members of this list first priority on registration. The
event is limited to 125 folks. We expect it to sell out. We've
selected a superb venue the Mandarin Oriental Miami located on South
Beach at Brickell Quay right on the water.
http://www.mandarinoriental.com/miami/
Because of committed sponsors like Net Objectives and Ultimate
Software we are able to keep the registration fee down to only $800
per person for the full 2.5 day event. Registration includes an invite
to our evening reception on February 18th courtesy of Ultimate
Software. Breakfast and coffee breaks are included all 3 days. Lunch
is included on Wednesday and Thursday 18th and 19th.
Wednesday 18th February - Keynote Alan Shalloway - Lean Track and
Kanban Track sessions
Thursday 19th February - Keynote Don Reinertsen - open space all day
Friday 20th February - Keynote David J. Anderson - lightning talks for
2 hours
Please register now to avoid disappointment and book your flights to
Miami. Please be sure to make a reservation with the hotel. Ask for
the "David J. Anderson & Associates" event rate of $250 per night. The
hotel has indicated that it will honor this rate for extended bookings
prior or post the event subject to availability.
Our confirmed speakers are:
David J. Anderson
Alan Shalloway
Dean Leffingwell
Don Reinertsen
Peter Middleton
James Sutton
Clinton Keith
Amit Rathore
Corey Ladas
Karl Scotland
Eric Landes
Eric Willeke
Reni Elisabeth Phil Friis
Alisson Vale
David Laribee
and not yet confirmed...
Max Keeler and Linda Cook
Bob Stoddard (from the SEI)
Sterling Mortensen
Many of these people are regular contributors to this group and have
together created and lead the kanban movement over the last 18 months.
I believe this is the finest list of proponents of Lean software
development ever assembled.
With our 2.5 day format, we have one day of sessions in two tracks,
one day of open space and half a day of lightning talks. This will
give all attendees the chance to work with the experts directly.
I also need to thank WordClay who have kindly offered to sponsor the
publication of the proceedings. Each attendee will receive a book of
the proceedings - papers written by our many speakers. The book will
be available to everyone else after the event. Price to be determined.
This idea has been forming among our architecture group this week and I think it has enough potential to open up for public discussion. I'm hoping to get some good criticism and references to prior art I can draw on.
Overview:
Traditional stories provide a solid structure for understanding what value a given set of work is supposed to accomplish (i.e. Analysis). They do not provide a good means of giving a team guidance on HOW that is to be accomplished. On the other end, we have a great set of practices from XP and other sources that provide a means of creating very good code through pairing, co-located teams, etc.
Unfortunately, there is a gap present in most organizations. Where do you create a consensus about the architectural metaphor, that set of patterns and approaches that allows a good application to scale beyond a single team. Things like SOA can pull that decision making process out to the extremes, where there's a small body at the top working with services as a language, and teams that then take individual responsibility for their parts, but that doesn't extend to UI-intensive applications or to the deep complexity inherent in some domains. The core of the message is that Agile doesn't "do" detailed designs. There's a good reason for that: Detailed designs traditionally create a large transaction cost for each unit of work going through the system. When you've reduced batch sizes, the transaction costs become a higher portion of the overall per-item cost, thus making the detailed designs painful.
The design story template is used as the next layer beyond an XP-sized analysis story. It provides a mechanism for crafting highly focused design with minimal transaction costs. It also allows for training other members of the team on the design approaches as a core part of creating the design. In essence, each design becomes the process of filling out a small, defined template in the same manner as writing an FDD feature name or writing a BDD story. The part of this that is most interesting to me is that the design story follows a standard order starting with most generic (the story-level goal) and proceeds to the very detailed (what methods need created). Because of this, the architect [1] may stop writing at any point and allow a developer to write the remaining elements. In our organization, it will be reviewed, and the last line will frequently be left off. In others, the architect may stop after the third line and let a highly capable team member take care of the rest with no further interaction. It is entirely by intent that this template includes aspects that are typically left to the developer and starts with items that are usually left to the analyst or project manager.
This is a bridge between the value vision and the implementation, and provides a clear path towards training developers to handle harder, more abstract aspects as a part of their work and in a manner that is clearly relevant to their work.
Story:
In order to improve the user's perceived performance through a reduction of RAM usage,
we need to load preview quality images for the current page only.
This requires to make changes to page display behavior in the client,
using the established page mediator pattern through the page mediator factory,
to provide interactions between the project model's page changed event and the placement rendering
by creating a mediator named CurrentPageImageVisibilityMediator,
and writing the handler ProjectModel_CurrentPageChanged event that uses an ImageLoad asynchronous command to change the quality of the displayed image if the current page has become visible or ceased being visible.
Template:
In order to [goal of the story],
we need to [Decomposed software change supporting story].
This requires us to make changes to [the architectural/design components]
using [Identified patterns and approaches specific to the team/product]
to provide [specific interactions with existing components of this system]
by creating [specific class names to implement the patterns]
and writing [specific method names and behaviors]
Goals:
This came out of a few needs at Inkubook.
- Developers wanting to grow in their craft and learn the design and architecture roles
- Architects wanting to maintain enough control of the system's shape, but be able to effectively delegate
- Keep batch sizes small, thus needing to
- Minimize the transaction costs of each batch.
- Different developers have different abilities, and the approach needs to scale to any of them.
- Need to identify responsibilities without overwhelming the process
- The need to provide meaningful review early in the design process
Influences:
There were a number of easily identifiable previous influences on how I was thinking, such as:
- Communication pattern of "Describe a need, then ask to have it described back to you"
- My understanding of FDD the concept of a Design Memo
- Knowledge of BDD's "examples" notation
- Desire to fit with an XP or BDD style "story" format and feel
- The concept of the cone of uncertainty
Shu Ha Ri
[2] A good description of Shu Ha Ri can be found here. To summarise, the concept comes from the Japanese martial art Aikedo and refers to the three stages of learning.
Shu is the first stage, where the student is imitating and following the master’s steps
Ha is the second stage, where the student is showing understanding, and breaking away from the master’s steps
Ri is the final stage, where the student is showing mastery and fluency by creating their own steps
Mapping the concept of Shu Ha Ri into this story template, I believe that developers will be able to progress through all three stages for each of the lines in the template, at times in parallel. I want to do more evaluation of the androgogical aspects of using this sort of progression for teaching our craft more effectively, but that is something for another day.
Notes
[1] I'm saying "architect" in the sense of "the person whose job is to define the approach used in designing the application and for teaching that approach to the various teams involved". I understand the role changes based on system size and organizational structure.
Hello all! It's been a good while since I've taken the time to do my own writing? Why is that? Here's your list of excuses... err... reasons.
First, and most importantly, I feel that this is the time of year when I should withdraw a bit from thep professional world and focus more attention on family and friends. It's been a good month, and many good times are being had by all.
Second, Inkubook.com's had a great series of releases. We released the ability to print calendars the week before Thanksgiving, and we've released several massive performance improvements in the weeks since. We're investing time now into using more of what the cloud has to offer, and as a result we're discovering even more performance opportunities.
Beyond that, I've been investing some of my remaining professional time into the local community. I spoke last month at the IndyNDA meeting, and then recorded a session with Larry Clarkin for The Thirsty Developer. This was released Monday at http://thirstydeveloper.com/2008/12/09/TheThirstyDeveloper44RealWorldSilverlight2.aspx.
Additionally, I've become very invovled with various online forums and groups related to impoving the software development experience, specifically I am a moderator on the kanbandev group on Yahoo and a frequent contributor on kanbandev, real_options_discussion, and SW-Improve. This has consumed much of my time. It also is shaping up that I may be a co-producer for one of the stages at Agile 2009 in Chicago, but I'll hold off further details until it's fully committed.
Merry Christmas to all!
Chipotle has the fastest service of any fast food vendor I go to. Rush hour, takes five minutes max. Go in when they're nearly empty and I can be out in under a minute. Feels faster than the best McDonald's times, even if it's not really. Why is this?
Chipotle does Kanban!
Why do I say this?
Their customer-facing staff are all generalists. They know how to work the register, make all the types of food, and warn the guys behind them when more supplies are needed.
They have a WIP limit of one order per person working the line. The cash register has its own WIP limit of one, or possibly two during the lunch rush.
Customers are the users, the food is the feature. The employees don't write requirements, they ask you just enough about what you want to satisfy the current stage of development.
The first employee pulls an order from the input queue, which is the line of waiting customers.
That employees take the order through the stages until there's another, non-busy employee next to them, then hand it off. There is no knowledge transfer, because there are no requirements beyond what's already piled on your burrito.
The first employee returns to pull the next customer, while the second employee works with the customer for beans, salsa, cheese, and so on, possibly allowing the next employee down the line to pull the customer's order forward.
At full employee capacity, there is one employee filling each stage and the customers move at a steady shuffle down the line. If there is no need for full capacity, then employees can clean tables, the kitchen etc while a smaller number of employees runs the food line.
At lower employee utilization, better (i.e. faster) employees are able to cover more stages, and are not limited in their performance by the process.
They do Kaizen events whenever something is screwed up. The employee will stop the line, solicit assistance from the adjacent employees or the kitchen as needed, and fix the problem. Work doesn't flow around in most cases because things are fixed very quickly and quietly.
Let's look at the key indicators:
They have work tokens (Customers) that utilize single piece flow (the order) and managed through WIP limits (Set dynamically by the resource count).
Resources pull work from station to station, avoiding all queuing for work in progress. (Technically, one order does queue before the cash registers most times)
They stop the line and resolve problems rather than allowing inventory to accumulate.
They have subordinated all other functions to the goal of minimizing customer lead time.
I’m typing this in the car on my way to Ohio to see the in-laws because I just
finished having an incredibly compelling discussion with my wife. My wife is an
educator and has a masters of education specialized in adult online learning
with a minor in curriculum design. We were discussing her frustration with some
of the course authors and facilitators she works with regularly and
transitioned to a discussion of how modern education as a whole interacts with
online learning and online degrees. I’m going to describe a bit of recent
educational history below. Please read this with the history of Agile, Scrum,
and the current evolution of Kanban approaches in mind. Please keep in mind
that I am intentionally disregarding correspondence schools going back into the
1800’s, although I could easily draw parallels there, too.
Online learning has spent the last two decades working very
hard to become an accepted mainstream approach. Initially, online learning was
used for niche training, and then degree programs began to become available
from a variety of small schools. A huge variety of approaches were tried
throughout the 90’s, with the good ones sticking and the bad ones quickly being
forgotten. In the late 90’s and into the early 00’s, the industry started to
consolidate with regard to the approaches and mechanisms used to deliver the
learning, as well as the formats that were adopted for structuring the
curriculum themselves.
Sound like the early agile movement? I find it interesting
that there are summarization books that collect the successful approaches for
online learning, just like Highsmith’s “Agile Software Development Ecosystems”
does for agile.
Now, with University of Phoenix having led the charge and
defined a highly effective “How” and then proven that it can be scaled very
profitably, there are a huge number of small schools starting to get involved
with their own programs. Additionally, the big, traditional universities are
taking notice of what’s happening and introducing their own online degree
programs. However, not only are the big schools years behind, they have a
number of difficulties trying to integrate this “new reality” with the
large-school mindset held by their administrations and tenured faculty.
I believe that sounds quite a bit like Scrum. It’s become
the de facto “way to do Agile”, and it’s a very good one. My wife’s Master’s
degree is from UOPHX, and I believe Scrum is vastly improved over traditional
methods, so I don’t mean this as a slam. The big universities fit well with the
issues faced by large companies trying to move towards agility.
The next wave is happening now. Back to where I started this
discussion, my wife was chatting about a survey of “Authentic Learning”
performed by her boss. This is where she sees the industry going next, and
she’s certainly applying the principles and practices of authentic learning to
her work, even before these principles and practices have accepted names or
approaches. The essence of authentic learning is in moving away from students
“learning how to be students” and towards “learning how to learn”. As an
isolated example, authentic learning stresses challenging students with
problems that have many possible solutions, rather than “traditional” problems
with a single, gradable answer. By the way, "authentic learning" is new the same way agile is new. People have done it for a long time, but it's hard, and takes work, so people don't do it out of laziness or lack of discipline.
This is where I see Kanban fitting it. It’s not the answer,
but it’s a positive move in the right direction, and it serves to move beyond
the status quo towards a meaningful improvement. Even better, not only does it
stress individually fitting solutions for the problems faced in development, it
includes the Kaizen improvement culture for Just In Time improvements to the
process. As an aside, I see Kaizen as being superior to the retrospective
approach used in Scrum because it is event driven (pull) instead of periodic
(push).
Now, we’ve done a great job pulling in many lessons from
manufacturing to use in improving our software development process. So many, in
fact, that manufacturing is becoming a very common metaphor, possibly even more
common than the previous metaphor of home construction. Guess what? We’ve hit
another single-metaphor system, and we’re driving straight towards stagnation
again. I believe that now is the time to begin pulling in more metaphors,
ideally those built on proven models. Education, with its many learning models,
has a lot to teach us. Science, with its well defined methods for belief and
proof, has a lot to teach us. Architecture has taught us patterns, and only
recently have people really applied those to processes. I think we can learn
quite a bit from service industries. Chipotle runs a very effective Kanban
process for burrito building, for example. Economics had a great deal to teach
us in managing incentives. The military could teach us a lot about specialized
training, and about layered planning and delegation, and about utilization of
specializations in a generalist environment, and about drastically changing the
intent and behavior of a large force in a short period. There are a nearly
infinite number of sermons out there that could be applied in various places.
Traffic management could teach us [more] about avoiding bottlenecks. Some of
these have been done already, some need to be done more, some might be brand
new. I don’t care, so long as the knowledge comes to us!
Summary: Go forth, find guidance and wisdom from other disciplines, bring it back. And share it.
I was a band member once upon a time. In middle school, I played French Horn for four years. Then, I didn't pick it back up for over 15 years until last December when my lovely wife gave me a wonderfully shiny silver French Horn for our five year anniversary, with the encouragement to start learning. I toyed with it on and off, remembering the fingerings from muscle memory and really getting into playing the basic songs in the books she bought me. However, I continually got discouraged because I was quite simply unable to hold a tune; the pitch of most every note was off by at least a half step, often a full step. I lived with this, and slowly got discouraged and the horn started gathering dust until a couple nights ago when we decided to try playing a duet with my wife on the baby grand.
"Let's just play some scales, maybe that'll help you find the pitch" C Major, here we come! C... sounds great! D... hmmm... E... that's off... and so on... right up the scale... only C and A seemed to be hitting consistently. After a while, I got frustrated, asked her to hold a note, and tried different fingerings until I got one to match the pitch. WTF? Why is this a 2-3 when I'm used to playing it as a 0?
Then came the dawning realization that banished my ignorance, my assumptions, and the sum total of my muscle memory. This wasn't the same horn! There are two types of French Horns - Bb and F. I grew up playing an F horn, this apparently was a Bb horn. So I got out a pencil, copied the Bb fingerings from my fingering chart onto the music, and started playing (very very slowly). Instant pitch! My problem wasn't a 15-year-old embouchure as I'd assumed for the last year, it was a disconnect of my core knowledge!
I should have remembered what I knew. Heck, I even read all about it in David Agans' book! FIGURE OUT THE PROBLEM BEFORE FIXING IT! Doh!
First, I'll repeat the news that's all over: Microsoft has released the "final" version of Silverlight 2.0 to the world! This is a major step for .NET developers, because it means we can do really incredible things on the web without massive injections of AJAX or having to learn Flash. For example, take a look at what we've done with Inkubook. However, there is a lot to be said about how Microsoft approached things.
I believe that until Friday, October 10th, Microsoft has led nearly a perfect game with regards to how they've managed Silverlight. Here's my perspective of what they did until now:
- Released a very minimal 1.0 edition that solved a small number of challenging problems in an elegant way.
- Very clearly communicated the known limitations of 1.0 while sharing plans for 2.0 as they became available.
- Released a very early build of 2.0 that generally did not break exiting 1.0 applications.
- Refreshed 2.0 with new released several times, clearly communicating both where the changes were likely to occur, and then what was broken as a result of earlier work.
- Successfully supported the Olympic Games with a Beta product with very few issues.
- Repeatedly engaged the community with what's going on throughout the process, with many Microsoft developers and program managers sharing the work in progress and building training material on their blogs.
- Taking the unprecedented step of releasing an RC0 a short time before the release of a web-based product would break many developers application. They told the community that we'd have a short notice before they released the real final version, but they wanted us to have a chance to get everything updated ahead of time.
Fourth Quarter, two minute warning, Microsoft up by a touchdown with the ball and all their timeouts remaining.
Can anybody out there please tell me what possessed Microsoft to change the game plan this close to the end? Here's what (to my perspective) happened:
- Friday, Oct 10, Microsoft announces a conference call for Monday the 13th through their PressPass site (http://www.microsoft.com/presspass/press/2008/oct08/10-10GuthrieSilverlightMA.mspx).
- Apparently, they also communicated a gag order internally, because nobody inside Microsoft blogged about Silverlight over that entire weekend with the exception of Jessie Liberty's ongoing Silverlight daily tutorials.
- As a result, many teams probably missed this call entirely. We were only aware of it through the vigilance of one developer... on a team where everybody tries to follow blogs and keep up on the tech we're using day in and day out.
- During the call (Monday, noon EST), Scott announces that Microsoft will be releasing Silverlight to the web "Tomorrow morning", with no more detail. Note that he essentially just said that "Sometime in the next 12-24 hours we will be turning off your web site unless you're ready.
- After the call (Monday, 1pm EST) we go into scramble mode, refreshing the prototype branch where we characterized the fixes to the breaking changes, merging it into our mainline build, and throwing the entire team at "making it work". Please note that this meant that means that most of our developers needed to install VS SP1 (1-2 hours), uninstall and reinstall the silverlight developer tools, runtime, and Blend (1-2 hours)... prior to this, we had one machine capable of building our site in RC0.
- Microsoft makes an updated breaking changes list available. This list includes a half-dozen new items. This list does NOT include a number of items that have been commented on public blogs between the publication of the two lists. There are a number of breaking changes that have affected me that are not on any list. (Examples: Negative border widths no longer valid in styles, changes to when ActualWidth is set relative to first Measure pass, introduced need to explicitly call ApplyTemplate in some cases)
- That afternoon (Monday, 3pm EST) through evening (Monday, 11pm EST) we flew through our code base... first, commenting out or deleting the bits that didn't work, then slowly fixing them back in once we got a baseline working.
- The first posts about it start coming out, and most of them aren't from MS employees (Monday, ~4pm EST)
- We put in place plans to put the site into maintenance mode as soon as we see evidence of the RTW,
- We go home (Monday, 11pm EST), planning on cleaning up further graphical glitches in the morning.
Now, you notice that this has a fairly happy ending, for which we're entirely grateful and I give full credit to my team for accomplishing this in less than 12 hours... even the new dev that just started yesterday stayed till 7pm and made meaningful contributions. This doesn't change my opinion of how Microsoft bungled this release.
I have personally lost a lot of trust in how Microsoft will support products on their Go-Live licenses. They've earned a lot over the last couple of years, but much of it was burnt today. I still don't know when they will flip the switch and turn on automatic updates to existing clients... which greatly impacts our release plans over the next week or so. At this point, I think I'm going to stop, and end with a few specific steps that Microsoft could have taken that would have saved my trust.
- Announce the plans to the world on Friday when they were clearly already set. If there was still a chance of calling it off, tell us that, so we can plan accordingly.
- Provide a specific forum to discuss the logistics with the community. Silverlight.net would be a great place for this. Who knows, maybe the community could suggest things to make it go more smoothly all around.
- Specify a single, authoritative place (blog, forum, web page, whatever) where we can get up-to-the-minute status of what's happing... is the RTW out there, is it available, etc?
Summary: Communicate - don't shut down at the most critical moment.[EDIT]
I very much appreciate the quick reaction from Tim Heuer at Microsoft. After exchanging a number of emails with him last night, I want to clarify a wee bit:
I am VERY IMPRESSED with how Microsoft communicated leading up to this release, right up until Friday of last week.
I am VERY IMPRESSED with the work produced by the Microsoft developers at a technical level.
I am VERY IMPRESSED with the road map that's been shared and followed.
I am VERY IMPRESSED with the efforts extended by most contact points to "make things right", especially Midwest architect evangelist Larry Clarkin.
However, I still have a core set of issues, which are summarized below:
Key issue: No warning was given of when and where the announcement
would take place. ScottGu didn't even post on his own blog that he'd be
making an announcement at 9am Monday.
Key issue: The information followed a different path than all other announcements did previously.
Key issue: The original announcement said it would be short, possibly
very short notice. I don't think many people understood that meant
"same day notice"
Key
issue: Monday's announcement said "we'll release this tomorrow
morning". Nobody clarified a) What time (i.e. 11pm PST?) or b) that
automatic update would/would not be turned on out of the box.
- Trust
- Value
- Integrity
These three things are what I find to be the three critical aspects of all of the professional (and personal) relationships I share.
Trust, for me, is continually completing the things I say I will do. Trust is easily built by committing to a small item, then successfully providing that small item. On the other hand, trust cannot be achieved by being told what to do and then doing it. I'll keep Kanban mostly out of this post, but this an aspect of why pull works. Trust can be lost, but it can also be regained, and even very low-trust relationships can be successfully transformed through the relentless pursuit of improvement.
Value is key, in business. Every relationship and communication carries transaction costs and coordination costs. Within the context of the responsibility your trust has permitted you, each individual must strive to provide maximal value to those around them. In exchange, that value will be returned, possibly multiplied. Perceived value is the down-payment on a relationship, delivered value is the rent. Words can create a relationship, but only actions can sustain it. Otherwise, casual (low cost) relationships will slowly wither, one-sided relationships will wither quickly with one person being frustrated, and painful (high-cost) relationships will be terminated. Often, the processes of gaining trust and delivering value are tightly related. However, value is very time-sensitive (here comes real options), while trust suffers only from the slow effects of entropy. This is how long-term partnerships are built across many short engagements.
Integrity is the cornerstone of all of these. Integrity is ethics, morals, and much more. Of these three topics, integrity is the only one that starts full, and it's the hardest to refill when it's been lost. Integrity can be lost, and it can be made visible to others. Occasionally, in exceptional circumstances, it can be regained. Integrity means that you stand up for what you believe, for the rights of others, and for just the "right thing". It means you admit your failures, and acknowledge the need to rebuild trust and value in the face of difficulties. It means you acknowledge and respect the trust and value offered by others, abstaining from activities that knowingly hurt others. Oh, and the other thing, integrity doesn't count when it's easy, you only get points for it when it's hard. Integrity is advising a competitor of a potential leak or security risk, rather than unethically using those errors. Integrity is accepting the fault for the entire project failing, and then doing something about it. Integrity is refusing to let the general apathy rule the day.
These three things are critical to myself, and to any enterprise with which I am associated. As my personal and professional networks expand I am also recognizing that each of these things has a network effect as well. The more people with whom I have engendered trust, the more default trust I seem to have from their trusted peers. This was especially visible at Agile2008. It was my first entry into the Agile world directly, but the trust and value exchanges with people at the APLN Summit two weeks before somehow gave me direct access into the speaker circle, and as a result I spent much of the conference learning (and hopefully helping others learn) with the most respected individuals there. What's more interesting, is that I can trace the chain of connections back to a single lunch I shared in Chicago during 2005. That chain could have been broken at any time by a failure on any of the three items above.
It was rather nice. For a few minutes earlier today, I was able to experience the designer's perspective of Blend. We had a bug filed on one of our common controls' visual appearance, and a designer and a developer were pairing on cleaning it up. They asked me how to structure something, and I was able to completely restructure the UI model of that component without making a single functional change. Yay for Expression Blend living up to one of its promises. Next step is to figure out how to make the experience more common, and help bring the silos closer together... let's make multi-grain! (err, that was really dumb, but once typed, it was hard to delete)
Every few months something triggers a series of thoughts in my head about overtime practices, behaviours, and incentives. Every time I think about it, my thoughts come back to a question of the relative incentives in the way our software development system. On many teams, the management group has the authority, while the developers have the ultimate power. The people with the authority have an easy answer: demanding overtime is a no-lose situation until the developers quit out of frustration. The developers, on the other hand, have two options: do the overtime, or quit. There is no incremental pain to the management team, while the developers suffer all of the incremental pain.
How do we fix this?
Neither extreme seems appropriate. There really are circumstances in every business where overtime should be required, because the value to be gained exceeds the costs inherent to the overtime. When there is little or no incremental cost to management, the value will always exceed it. Thus, maybe the question becomes "How do we set a meaningful cost of overtime?" A few options could involve paying out overtime (direct financial cost), comp time (borrowing time), or even trading overtime for allowing developers to choose a week's worth of internal improvement work (options/control cost). (This third option is exciting to teams that want to produce better code but have been in "rush to release" mode for too long).
There is no general solution, I fear. Any solution needs to account for the personal situations of the developers and the project.
One thing I do know for sure: there is much less bitterness when the managers are in the building on the weekends too. There was one time on our last overtime drive when there were three levels of managers (the last of which reports directly to the CEO) there on a Saturday, just to support the developers and make sure nothing was blocking.
There is no need to attempt to determine the net effect of cities on costs in general. First of all, there is no such thing as costs in general. There are particular costs that matter differently to particular individuals and enterprises, and those individuals and enterprises can weigh for themselves the various costs and benefits that affect them. The assumption that third-party observers can make better decisions than the people directly involved has produced many urban fallacies and many economic and social disasters. The belief that third parties with no stake in the outcome are empowered, morally as well as politically, to override the decisions of those who do have a stake in the outcome has been institutionalized in 'city planning' studies at universities, in 'smart growth' laws and policies, and in various crusading movements to stop 'urban sprawl' or to cure neighborhood 'blight' - as third parties choose to define these terms.
I came across this quote by Mr. Sowell (page 39) in the course of my normal reading, and it seems to follow with what I currently see happing in the Agile community. One of the overriding feelings I have after Agile 2008 is that many people believe "Agile == Scrum". Since I've never done a full implementation of Scrum/XP, it's hard to say (I'll cover my path somewhere else). But, to the point.
Reread Sowell's paragraph again, only replace "cities" with "processes", replace "urban" with "project", and then drop various agile methodoligies in for "city planning" and "smart growth" and various "bad project smells" in for "urban sprawl" and "blight". what do you get?
Think about it. This is what agile set out to fix, but now it is what agile as become. Instead of "too much documentation" and "analysis paralysis", we've got "fixed length iterations" and "Test first". Are we condemned to always put bandaids over what we've got? We know that it is much harder to take away a process than to add it in most cases, and this matches well with what Sowell sees about property laws and regulations. It is good that our community continues to learn, and continues to evolve, but we must focus on allowing that evolution to take its course wherever it may go. We cannot allow ourselves to fall into the trap of holding certain tenets sacred. These tenets slide their way into the core of our culture, and become very hard to excise. They're everywhere, and they're taken for granted in many cases. Things like "The CMMi is too heavy, and useless" and "Waterfall is innately bad". Invididuals may question these tenets, but changing that opinion in the community is a challenge that may go nowhere.
What's next? How do we prevent ourselves from falling down? How do we prevent the concept of agility from being tied down by the paradigm of Agile? Or, as has been talked about before, how do we avoid the need for a post-agile movement? There's effort in this direction, but it is also has the potential to become a major holy war.
This post is all over the place, which nicely matches where my brain is going as I think about this, but the core lession I've learned about this today is that I have another domain I can use to inspire improvement in the software community. The problems are all the same, and everybody else has solved them for us. Let us lead this community, a community devoted to learning, out to other fields of knowledge and find those people who have solved our problems before. Look in the learning of the building architects, the city planners, the economists, the mechanical and civil engineers... all of these long-established disciplines that have a history of running [mostly] successful projects. We've leaned from Manufacturing, but where else can we look?
References:
Sowell, Thomas. (2008). Economic facts and fallacies. Basic Books, Cambridge MA.
Wow, so much I probably should talk about, but I don't even know where to start. Massive amounts of networking, information, realization, and even contribution going on, and I can't unravel it at all right now. I think there's a lot of potential for transforming this into real, meaningful changes in my current environment, but I need to be cautious in how I approach things. I firmly believe in a few core changes that I think will drastically amplify the performance of our extended development group, but I can't just say "we need to do this"... I need to inspire people to _want_ an understanding of how it will help, and then I can happily and easily teach the basis of pull-based, work-limited techniques and explain what changes I expect to see appearing.
In other news, I had a great lunch with Chris S. today and am very excited to hear about the connections he made at the conference. He has a great opportunity to become a leader in the emerging area of Real Options within the Agile community and could extend both his personal brand and his current company's brand though developing those opportunities. Chris, go for it!
Finally, my brain's operating at a process level, and this post is hopefully a means to allow me to dump some of those thoughts and focus back on the code I need to write today. Maybe I shouldn't have started out touching the part of the system where the changes HAVE to be right, since it's the core factory of an entire tier.
Wow - it's been over thirty days since my last post. What's changed since then?
First, we've put http://inkubook.com into production. I'm very proud of the work I've done and that my team has done on this one. We killed ourselves getting it done, but this is the product of just six months of work of the team. We took a new technology, started coding against Silverlight 1.0 and had a working version of the book editor functioning with the ability to print books by March 31, then we dug right back in and built out the same capability in Silverlight 2 Beta 1. This was some of the most fun I've had as a developer, ever. We reached functional parity and more in about two months, then added a few key feature areas around photo manipulation and text handling as well as making the entire thing look a LOT better than it did.
Second, I went to Seattle to the APLN Summit and learned an incredible amount from the people I met there. The speaker list was stellar, and the format was incredibly useful for getting professionals to interact with the experts on a variety of topics. Lots of pictures up on Flickr.
Third, at a personal level I've been doing a lot of refocusing on what's important in my life. I've dropped some of my weekly commitments and will continue to do so. I've made a commitment to spend more time at home in the evenings. I've started making an improved effort to reconnect with my peers from various engagements and spend time over beer chatting about technology. I'm refocusing on learning, because I've allowed my focus to drift too far towards execution.
Our team has decided to take a step back towards scrum and away from our previous semi-Kanban approach. I think that it's a good plan at this time, although I also suspect that many of the benefits of our earlier approach will continue to show through.
Why did we do this? Here's some of my thoughts. They do not at all reflect the thoughts of anybody else on my team or in my company.
- We were unable to fully realize the benefits of Kanban. For example, we had a visual mapping of our value stream, but we never made the transition to using that visualization to improve how the team communicates within itself or to the outside.
- We lacked the process maturity to accurately forecast release dates for specific features based on lead times and SLA. I believe this was in large part due to the ongoing issues we've had with controlling batch size (both too large and inconsistently sized). I think we'll be able to better do this in the future, but the current failures did not go a long way to building trust in our approaches with stakeholders.
- We had early success with Scrum before we changed product targets. Scrum has been highly effective for our management team in planning features at a high level. I believe that ordering and allowing the dev group to choose the amount of focus on each one would be more productive overall; however, we've had issues in determining a good order, and we've struggled to structure a good focus across roles within the group.
I anticipate that our "outward facing" status and planning will be Sprint-based, while our internal approach will remain somewhat Kanban. The sprint backlog will serve as our feeding buffer, while we'll manage how much work we allow to be active amongst the team during a sprint the same way that we are now. The biggest difference is that our in-process lead time is artificially fixed at 30 days and our overall response time to external requests will average around 45 days.
In the beginning, there is no resume, only an application.
Then, there is the resume.
Later, the resume becomes an afterthought, used to round out the paperwork.
Until, eventually, there is no resume, only trust.