• The two main concepts of Kanban is to keep the queues minimum and to maintain visibility.
• Management/leadership needs to make sure the Kanban Queue doesn?t get starved.  This is key and also very challenging, being the queue needs to be minimal but also can?t get too small during the course of work.  This is to maintain maximum velocity.
• Phases of the Kanban need to be kept flowing too, bottlenecks need removed ASAP when brought up.
• Victory Wall ? I dig that idea.  Somewhere to look to see the success of the team.
• The POs work in Rally or other tools for some client management, but it causes issues with the lack of “visibility” ? a key fundamental ideal & part of Kanban.
• One of the big issues is fitting things into a sprint, when Kanban is used with Scrum, but longer sprints are wasteful.
• Kanban work sizes are of a set size.

At this point I got a bit side tracked by the actual conversation and missed out on note taking.  Overall, people doing Kanban and Lean Style Software Development I would say are some of the happiest coders around.  The clean focus, good velocity, sizing, and other approaches that are inferred by Kanban help developers be the rock stars and succeed.

This is definitely a topic I will be commenting on a lot more in the near future.

The session convened and we began a discussion about why collaboration is so hard.

• To work together in software better us engineers have to overcome traditional software approaches (silos of work) and the human element of tending to go off in a corner to work through an issue.
• It was agreed upon that software engineers are jack asses of jack assery.
• Breaking down the stoic & silent types by presenting a continuous enthusiasm until the stoic and silent types break down and open up to the group.  Knowing it is ok to ask the dumb question or work through basic things once in a while.
• Non-work interactions are pivotal to work related collaboration.
• Collaboration is mostly autonomous of process (i.e. Agile or Waterfall)
• Latency time should be minimal in the feedback loop for software development.
• Collaboration is enhanced by Agile Ideals, and things like Scrum or Lean Process.
• Agile is not a process, Lean and Scrum are process.  Agile is an ideal.
• Lean, Agile, Scrum, Waterfall, Six Sigma, CMMI, oh dear. . .

Great session.  Off to the next session and more brain crunching. . . weeeeeeee!

I dived into the MEF session with Glenn Block, Sourabh Mathur, Brian Henderson, and others.  Glenn covered the basic architectural ideas of MEF and then dived into a few examples.

• Is a framework around decoupling components.
• Built around the idea of discoverable type systems.
• Traditional extensibility mechanisms have a host and the respective extensions, commonly linking these two aspects with a form of registration.
• MEF removes the need for the registration part of the architecture and uses a contract.
• At some point with MEF you get down to parts, which removes even the complexity of a host or extensions, but a truly evolvable architecture based on natural growth of parts.
• Also referred to as the framework that removes the “new” keyword.
• The idea is that parts pull together other parts that they need.  Between each part is a contract.
• Each part has imports or exports for the parts it needs or the things it offers.

If one checks out the MEF Codeplex Site you will find a host of additional information.  The framework download also has some decent examples that help one get kick started.

This is a topic I know nothing about, and thus, may be supremely disparate notes.  Have fun translating.  : )   . . .and coolness that the session is well past capacity.

• Separates things form the UI and everything that needs populated is done through commands.  The domain and reports have separate storage.
• Events populate these stores of data, such as “sold event”.
• What it looks like, is that the domain controls the requests by event, which would be a product order or something similar.
• Event sourcing is a key element of the logic.
• DDD (Domain Driven Design) is part of the core basis for this methodology/structure.
• The architecture/methodology/structure is perfect for blade style plugin hardware as needed.
• Good blog entry DDDD: Why I love CQRS and another Command and Query Responsibility Segregation (CQRS), more, CQRS ? la Greg Young, a bit by Udi Dahan and there are more.  Google, Bing, etc are there for a reason.

It appears the core underpinning architectural element of this is the break out of unique identifiable actions, or I suppose better described as events.  Those events then act upon specific pipelines such as read requests, write requests, etc.  I will be doing more research on this topic and will have something written up shortly.  At this time it seems like nothing new, just a large architectural break out of identifiable needs of the entire enterprise system.  The reporting is in one segment of the architecture, the domain is in another, hydration broken out to interfaces, and events are executed to incur events on the Reports, or what appears by the description to be events on the domain.

Anyway, more to come on this later.

Below are the notes I made in the REST Architecture Session I helped kick off with Andrew.

• RSS, ATOM, and such needed for better discovery.  i.e. there still is a need for some type of discovery.
• Difficult is modeling behaviors in a RESTful way.  ??  Invoking some type of state against an object.  For instance in the case of a POST vs. a GET.  The GET is easy, comes back as is, but what about a POST, which often changes some state or something.
• Challenge is doing multiple workflows with stateful workflows.  How does batch work.  Maybe model the batch as a resource.
• Frameworks aren?t particularly part of REST, REST is REST.  But point argued that REST is modeled, or part of modeling a state machine of some sort? ?
• Nothing is 100% reliable w/ REST ? comparisons drawn with TCP/IP.  Sufficient probability is made however for the communications, but the idea of a possible failure has to be built into the usage model of REST.
• Ruby on Rails / RESTfully, and others used.  What were their issues, what do they do.  ATOM feeds, object serialized, using LINQ to XML w/ this.  No state machine libraries.
• Idempotent areas around REST and single change POST changes are inherent in the architecture.
• REST ? one of the constrained languages is for the interaction w/ the system.  Limiting what can be done on the resources.  – disagreement, there is no agreed upon REST verbs.
• Sam Ruby ? RESTful services.  Expanded the verbs within REST/HTTP pushes you off the web.  Of the existing verbs POST leaves the most up for debate.
• Robert Reem used Factory to deal with the POST to handle the new state.  The POST identifying what it just did by the return.
• Different states are put into POST, so that new prospective verbs, without creating verbs for REST/HTTP can be used to advantage without breaking universal clients.
• Biggest issue with REST services is their lack of state, yet it is also one of their biggest strengths.  What happens is that the client takes up the often onerous task of handling all state, state machines, and other extraneous resource management.  All the GETs, POSTs, DELETEs, INSERTs get all pushed into abstraction.  My 2 cents is that this in a way ends up pushing a huge proprietary burden onto the REST services often removing the point of REST to be simple and to the point.
• WADL does provide discovery and some state control (sort of?)
• Statement made, “WADL” isn’t needed.  The JSON, XML, or other client side returned data handles this.

I then applied the law of 2 feet rule for myself and headed to finish up these notes, post to the Wiki, and figure out what I was going to do next.  For the original Wiki entry check it out here.

I will be adding more to this post with a subsequent post.  Please do feel free to post your thoughts and ideas about this, as I am sure everyone in the session will have more for elaboration.