Skip to content


Design Your Agile Project, Part 1

Johanna Rothman - Thu, 03/13/2014 - 17:11

The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in general.)

One of the nice things about Scrum is the inspect-and-adapt approach to it. Unfortunately, most people do not marry the XP engineering practices with Scrum, which means they don’t understand why their transition to agile fails. In fact, they think that Scrum alone, without the engineering practices, is agile. How many times do you hear “Scrum/Agile”? (I hear it too many times. Way too many.)

I like kanban, because you can see where the work is. “We have a lot of features in process.” Or, “Our testers never get to done.” (I hate when I hear that. Hate it! That’s an example of people not working as a cross-functional team to get to done. Makes me nuts. But that’s a symptom, not a cause.) A kanban board often provides more data than a Scrum board does.

Can there be guidelines for people transitioning to agile? Or guidelines for projects in a program? There can be principles. Let’s explore them.

The first one is to start by knowing how your product releases, starting with the end in mind. I’m a fan of continuous delivery of code into the code base. Can you deliver your product that way? Maybe.

How Does Your Product Release?

I wish there were just two kinds of products: those that released continuously, as in Software as a Service, and those with hardware, that released infrequently. The infrequent releases release that way because of the cost to release. But, there’s a continuum of release frequency:

Potential Release Frequency

Potential for Release Frequency

How expensive is it to release your product? The expense of release will change your business decision about when to release your product.

You want to separate the business decision of releasing your product from making your software releaseable.

That is, the more to the left of the continuum you are, the more you can marry your releases to your iterations or your features, if you want. Your project portfolio decisions are easier to make, and they can occur as often as you want, as long as you get to done, every feature or iteration.

The more to the right of the continuum you are, the more you need to separate the business decision of releasing from finishing features or iterations. The more to the right of the continuum, the more important it is to be able to get to done on a regular basis, so you can make good project portfolio decisions. Why? Because you often have money tied up in long-lead item expenses. You have to make decisions early for committing to hardware or Non Recurring Engineering expenses.

How Complex is Your Product?

Let’s look at the Cynefin model to see if it has suggestions for how we should think about our projects:

CynefinI’ll talk more about you might want to use the Cynefin model to analyze your project or program in a later post. Sorry, it’s a system, and I can’t do it all justice in one post.

In the meantime, take a look at the Cynefin model, and see where you think you might fall in the model.

Do you have one collocated cross-functional team who wants to transition to agile? You are in the “known knowns” situation for agile. As for your product, you are likely in the “known unknowns” situation. Are you willing to use the engineering practices and work in one- or two-week iterations? Almost anything in the agile or lean community will work for you.

As soon as you have more than one or two teams, or you have geographically distributed teams, or you are on the right hand side of the “Potential for Release Frequency” chart above, do you see how you are no longer in the “Complicated” or “Obvious” side of the Cynefin model? You have too many unknowns.

Where Are We Now?

Here are my principles:

  1. Separate the business decision for product release from the software being releaseable all the time. Whatever you have for a product, you want the software to be releaseable.
  2. Understand what kind of a product you have. The closer you are to the right side of the product release frequency, the more you need a program, and the more you need a kanban to see where everything is in your organization, so you can choose to do something about them.
  3. Make sure your batch size is as small as you can make it, program or project. The smaller your features, the more you will see your throughput. The shorter your iteration, the more feedback you will obtain from your product owner and “the business.” You want the feedback so you can learn, and so your management can manage the project portfolio.
  4. Use the engineering practices. I cannot emphasize this enough. If you do not keep your stories small so that you can develop automated unit tests, automated system tests, use continuous integration, swarm around stories or pair, and use the XP practices in general, you will not have the safety net that agile provides you to practice at a sustainable pace. You will start wondering why you are always breathless, putting in overtime, never able to do what you want to do.

If you have technical debt, start to pay it down a little at a time, as you implement features. You didn’t accumulate it all at once. Pay it off a little at a time. Or, decide that you need a project to prevent the cost of delay for release. If you are a technical team, you have a choice to be professional. No one is asking you to estimate without providing your own safety net. Do not do so.

This post is for the easier transitions, the people who want to transition, the people who are collocated, the people who have more knowns than unknowns. The next post is for the people who have fewer knowns. Stay tuned.

Categories: Blogs

Updated: Planning Game for Agile Estimation

Learn more about our Scrum and Agile training sessions on

I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing.  The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book.  There are also two links added at the end of the article.  One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.

Please share!
Categories: Blogs

Build A (local) Webcam With WebRTC In Less Than 20 Lines!

Derick Bailey - new ThoughtStream - Thu, 03/13/2014 - 14:00

WebRTC is all kinds of super ninja epic awesomesauce stuff. If you haven’t looked in to it yet, you’re going to want to get on that soon. I’d suggest starting with the HTML5 Rocks post on getUserMedia.

Build Your Own Web Cam

Just how awesome is it? You can build a web page that shows your webcam and hooks up your microphone in 20 lines of JavaScript… and that includes feature detection with an error message for browsers that don’t support it!

  var mediaOptions = { audio: false, video: true };

  if (!navigator.getUserMedia) {
      navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia;

  if (!navigator.getUserMedia){
    return alert('getUserMedia not supported in this browser.');

  navigator.getUserMedia(mediaOptions, success, function(e) {

  function success(stream){
    var video = document.querySelector("#player");
    video.src = window.URL.createObjectURL(stream);

The gist of it is this:

The first few line sets the options to ignore audio and get video. The next 3 lines do a bit of browser normalization to make sure “getUserMedia” is available. Then do the other half of feature detection, and exit the IIFE if it’s not available at all. Once you’re certain it’s ok, run the getUsermedia with the options that were previously set. If there’s an error, report it via console. If there’s no error, run the success function and tell the <video> element to play the video from the webcam.

You’ll need a couple lines of HTML and to make it look nice, a bit of CSS, too.

<!doctype html>
    <title>WebRTC WebCam</title>
    <link rel="stylesheet" href="webcam.css"/>
    <script src="webcam.js"></script>
  <video id="player" autoplay="true"></video>

body {
  margin: 0px;
  padding: 0px;

#player {
  width: 100%;
  height: 100%;

Note the use of the “autoplay” setting in the <video> element. Without this, you’ll just get a freeze frame from the video. The CSS just makes the video element huge, which is fun.  

How Well Does It Work?

See for yourself, with this fancy schamcy JSBin (and make sure you hit “allow” when your browser prompts you to access your camera:

WebRTC WebCam

If this doesn’t work for you, you’ll end up seeing a link that just says “WebRTC WebCam”… which won’t surprise me if you’re reading this in an RSS reader or in Safari or Internet Explorer. WebRTC is only workable in Chrome, Firefox and Opera at the time that I’m writing this. Be sure to check the usual “is it ready?” sites, for more info:

Be More Awesome

From here, there are a lot of things you could do with WebRTC, including real-time chat rooms with audio and video. This gets pretty hairy pretty quickly, though. You’ll need to get some crazy STUN server awesomeness going in order to get peer to peer negotiations of video and audio formats handled. It’s a bit of a mess, at the moment, quite honestly. But the future looks amazing. And I’m diving in head first.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Definition of Ready

Agile & Business - Joseph Little - Thu, 03/13/2014 - 03:04

Gabriel asked:
Hi Joe,
Can you recommend few good sources for “Definition of Ready” ?


I like Jeff Sutherland’s stuff.

Did you see this?

It includes an article.  Read that.

As he taught me, the DOR is flexible team by team.  Each team must decide on the details of a DOR, based on the needs of the team members, the PO, the type of product, etc.

And from their experience (what works, what doesn’t).

One key thing: eliminate anything the Team  (Doers) do not use.  Do not over-document.
See also Jeff’s blog on the Enabling Specification. (I also have some blog posts on this topic.)

And see my earlier post on getting to Ready.
Regards, Joe

Categories: Blogs

The Start of a True Team

I wrote this article for our Real Agility Newsletter, but I wanted to share it here too, just in case some of you don’t get it.  I think this is important to share because it gets to some of the deep values of Agile and good teamwork.

- – - – - – - -

The team really is important. Last month I wrote about love. This month, I’ll write about commitment. Our team has gone through some extreme tests this last month. Commitment kept us together.

Our business has been through crisis before. In the second half of 2005, my own financial mis-management led to near-bankruptcy for the business and for myself personally. My dear long-suffering wife and business partner, Melanie, kept things under control as we recovered. In late 2009 the Great Recession hit us hard and we had to cut our staff back to just Paul and myself by laying off three talented friends and cutting work to a loyal subcontractor. That was incredibly painful for everyone involved. A similar crisis occurred again in late 2011, although it wasn’t as severe. In September last year, our projections were showing a looming crisis… but we narrowly averted any layoffs when a smaller consulting deal closed and one person was let go for unrelated reasons. We still needed more work, and in late fall we were expecting to close three important deals.

In January we knew we were in trouble. Business was not booming. In fact, those three important deals had fallen through with nothing obvious on the horizon to replace them. Our office management was in a shambles with two recent changes in staff and very little continuity. Our accounts receivable had several items that were waaaay overdue. We were starting to dig deep into our operating credit with no obvious way to climb back out. The partners, Paul, Travis, Melanie and I started to talk about serious stuff: deep layoffs. We were worried we may even have to cut all the way back to just me doing work (mostly CSM classes) – a staff level we haven’t seen since 2007!

Two weeks ago, the four partners had an emergency weekend meeting after our early February attempts to build sufficient immediate cash flow failed. We consulted for over four hours around a single question: what should we do? Our projections were showing us running out of credit in just four weeks, our business development pipeline was almost empty and the few things in it were clearly long-shot deals, at least in the timeframe we needed. It seemed almost impossible to avoid deep layoffs. Our love for each other seemed almost irrelevant to the crisis, despite the depth of our feeling.  The consultation was difficult and filled with despair.

My memory for exact words is poor. I remember concepts, relationships and feelings. During that weekend consultation, one thing really stood out: we started to talk about commitment. We talked about what it would mean to be committed to each other and to the business vision of transforming people, process and culture. Most powerfully, we talked about the commitment of our newest employee, Nima, who seemed determined to go to the ends of the earth, to the very last moment to help us all succeed. As we talked about commitment, we came to our most powerful decision: sink or swim, we are all in this together to the end.

After that critical point in our discussion, we set some goals, determined some important activities, and decided to go literally day-to-day in deciding if it was time to wrap up the business. And, strangely enough (I say ironically), we decided we needed to shorten our planning cycle from a month to two weeks, increase the discipline of our team’s interactions to bi-daily check-ins, create a detailed set of dynamic plans for the two weeks, and have a review meeting at the end of the two weeks. Sounds a bit like an Agile team, doesn’t it?

What happened? Well, we’re still around. We’ve closed enough business that our projections are now showing us staying in a steady state financially for the next three months. That’s a dramatic turnaround from just two weeks prior. We aren’t going to run out of credit. In fact, we now have enough prospects that we expect to be extremely busy in just a couple more weeks. Our end-of-cycle review, which happened on Friday, was still difficult. There is still great uncertainty about many things. But the one thing that is crystal clear, strong as steel, and deep as the deepest ocean is our commitment to each other to succeed together. We are a true team.

- – - – - – - -

If you have similar stories to tell, I would love to hear them!

Please share!
Categories: Blogs

Avoid many-to-many mappings in ORMs

Jimmy Bogard - Wed, 03/12/2014 - 15:30

Going through and reviewing the Contoso University codebase, really to get caught up on EF 6 features, I found a relationship between two tables that resulted in a many-to-many mapping. We have these tables:


A Course can have many Instructors, and a Person (Instructor) can have many Courses. The EF code-first mapping for this relationship looks like:

    .HasMany(c => c.Instructors).WithMany(i => i.Courses)
    .Map(t => t.MapLeftKey("CourseID")

The NHibernate mapping would look similar, with a .ManyToMany() mapping on one or both sides of the relationship. From the Course and Person entities, I treat the one-to-many direction as a normal collection:

public class Course
    /* Blah blah blah */
    public virtual ICollection<Instructor> Instructors { get; set; }

public class Instructor : Person
    /* Blah blah blah */
    public virtual ICollection<Course> Courses { get; set; }

From each direction, we don’t ever interact with the junction table, we just follow a relationship from each direction as if it were a one-to-many. There are a few reasons why I don’t like this sort of modeling. Many-to-many relationships are normal in databases, but in my entity model I don’t like treating these relationships as if the junction table doesn’t exist. Some of the reasons include:

  • No place to put behavior/data concerning the relationship. There is no CourseInstructor class to add properties to
  • In order to navigate a direction, I have to query through the originating entity, instead of starting with the junction table
  • It’s not obvious as a developer that the many-to-many relationship exists – I have to look and compare both sides to understand the relationship
  • The queries that result in this model often don’t line up to the SQL I would have written myself

For these reasons, I instead always start with my junction tables modeled explicitly:

public class CourseInstructor
    public virtual Course Course { get; set; }
    public virtual Instructor Instructor { get; set; }

From each side of the relationship, I can decide (or not) to model each direction of this relationship:

public class Course
    /* Blah blah blah */
    public virtual ICollection<CourseInstructor> Instructors { get; set; }
public class Instructor : Person
    /* Blah blah blah */
    public virtual ICollection<CourseInstructor> Courses { get; set; }

Many times, I’ll even avoid creating the collection properties on my entities, to force myself to decide whether or not I’m constraining my selection or if I really need to grab the entities on the other side. I can now build queries like this:

courses = db.CourseInstructors
    .Where(ci => ci.InstructorID == id)
    .Select(ci => ci.Course)

I can skip going through other side of the many-to-many relationship altogether, and start straight from the junction table and go from there. It’s obvious to the developer, and often times the ORM itself has an easier time constructing sensible queries.

I do lose a bit of convenience around pretending the junction table doesn’t exist from the Course and Instructor entities, but I’m happy with the tradeoff of a little convenience for greater flexibility and explicitness.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Scaling Retrospectives

Leading Agile - Mike Cottmeyer - Wed, 03/12/2014 - 15:03

look forward

The Plea
Retrospectives are near and dear to my heart. I love facilitating them to this day and tend to try something new quite often. I have found it to be a fertile ground for learning facilitation techniques.  Today I will discuss scaling retrospectives. While the scaling discussion is receiving a great deal of press in the agile world these days, we have overlooked the retrospective area in my opinion. Time for a change:


The Setup
Consider the following two intents:
The intent of a team retrospective is to seize the opportunity to inspect itself and to plan for improvements the following iteration.

The intent of a program team and a portfolio team is to serve one tier below and maximize the value creation from those tiers.  While I may dive into alternative approaches for the portfolio level teams in the future, for now I will focus in on the program team.


The Pitch
Given the two aforementioned intents, let’s take a look at the agile manifesto by grabbing just a few of the guiding principles. As we go through, think about the scaled agile team at the program team level. How could they as a team make each of these better?

Simplicity–the art of maximizing the amount of work not done–is essential.
The art of evolving a plan. Planning is an essential part of flowing work through a scaled agile system. Not having an effective planning cadence from the strategy of the organization down to the delivery teams’ user stories can kill organizations. Moreover, the way you plan may not even fit your business model. Everyone, especially the program team, is responsible for maximizing the amount of work not done to get value out of the system. So what improvements can be achieved through progressive elaboration, story mapping, etc. for your program team? What practices do they need to keep or stop doing?

Working software is the primary measure of progress.
Pop quiz hot shot. Who’s responsible for working software? Many agilists focus on the scrum delivery teams and hold their feet to the flames. While my development brethren (shout out .Net devs) should not shirk their responsibility, I’ll tell you that it’s the program team that takes on a larger portion of the responsibility because they can make a gigantic difference in how organizations deliver a solution.  The program team is responsible for making strategic decisions as to when and when to not take on less than desirable software. This forces the quality decision to the correct spot. The program team should be focused on maximizing the value the delivery teams provide and any good product owner knows that a short term win by reducing quality is just that, short term and very costly in the end.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This one is all about the organization enabling the delivery teams to do well. I would ask all program teams to pay attention to the last sentence. How can you best enable your delivery teams to get the job done? Working with them to give them a clear understanding of the vision. Slicing stories better. Helping to protect the team’s capacity. Identify what it is and go make it better.


The Handoff
It would be easy to look at all of the principles and discuss for the program team. While that’s too big an undertaking for this blog entry, I’ll leave you with the last manifesto principle:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If we have defined above, albeit a small part, what it means to be a successful program team, then we can and should easily retrospect on what it would take to make the team even better.  This means that we should establish a cadence or rule as to when we will either retrospect or “stop the line” to reflect on the desired outcome for scaled teams.

Here’s what I want from you.  Not many people I know are testing this stuff out.  So test it with me.  Give me feedback as to what you have tried.  What success have you found if you tried a retrospective at the program team level?  What failed?  What do you need to start and stop doing?  Sound familiar?


The post Scaling Retrospectives appeared first on LeadingAgile.

Categories: Blogs

First book: Who is Agile in Australia and New Zealand is published

Agile World - Venkatesh Krishnamurthy - Wed, 03/12/2014 - 10:22


I had the privilege to  Co-Author  my first book “Who is Agile in Australia and New Zealand”  with  Renee  and Sunish .  This book is available for purchase from here

This book is a collection of interviews with passionate Australia & New Zealand agilists who answer the following questions:

1. What is something people usually don’t know about you but has influenced you in who you are?

2. What would have become of you, if you were not doing the job you do today?

3. What is your biggest challenge and why is it a good thing for you?

4. What drives you?

5. What do you think makes a great team?

6. What is the essence of Agile?

7. What is the last book you have read and which book made a huge impact in your life?

8. If you were going to have a dinner party with anyone alive or deceased - which three people would you invite and why?

9. What is the one piece of advice you would give to someone just starting with Agile?

10. What question do you think I should also ask and what is your answer?

11. Whom do you think we should ask next in Australia and/or New Zealand and why do you feel they should be included in the book?

Based on the original "Who Is Agile" book, this book is a regional version for Australia & New Zealand. Whether you’re a novice or an Agile Guru, this book is going to help you learn a bit about the people behind the names & get their perspective on Agile.

Categories: Blogs

Which Agile adoption Strategy is good for my company ?

Agile World - Venkatesh Krishnamurthy - Wed, 03/12/2014 - 09:46

image  The statistics I have seen recently give me a euphoric feeling about the pace of Agile adoption. However, I feel that most of the so-called "Agile projects" are just the "water-Scrum-fall," which no one is willing to admit. I could list various reasons behind the failure, but one thing that stands out clearly is a poor Agile adoption strategy.

Organizations generally go with copying the practices/strategies from other popular brands/companies with the assumption that it works for them. In reality, it won’t.  Every practice is context dependent, and since each company is different the strategies adoption should be different.

In this Cutter article, I write some of the secret ingredients that fuel the strategies.  Check this article out:


Photo Courtesy

Categories: Blogs

Efficient querying with LINQ, AutoMapper and Future queries

Jimmy Bogard - Tue, 03/11/2014 - 21:31

Even after all these years, I’m still a big fan of ORMs. One common complaint over the years is people using ORMs use the tool identically for both reads and writes. With writes, I want tracked entities, managed relationships, cascades and the like. With reads, I don’t need any of that gunk, just an efficient means of getting a read-only view of my data. If I need to make multiple queries to gather the data, this often results in queries that return lots of data over multiple round-trips.

We can do better!

Let’s say we have a controller action (taken from the Contoso University Entity Framework sample) that pulls in instructor, course, and enrollment information:

public ActionResult Index(int? id, int? courseID)
    var viewModel = new InstructorIndexData();
    viewModel.Instructors = db.Instructors
        .Include(i => i.OfficeAssignment)
        .Include(i => i.Courses.Select(c => c.Department))
        .OrderBy(i => i.LastName);
    if (id != null)
        ViewBag.InstructorID = id.Value;
        viewModel.Courses = viewModel.Instructors.Where(
            i => i.ID == id.Value).Single().Courses;
    if (courseID != null)
        ViewBag.CourseID = courseID.Value;
        viewModel.Enrollments = viewModel.Courses.Where(
            x => x.CourseID == courseID).Single().Enrollments;
    return View(viewModel);

This doesn’t look so bad at first glance, but what isn’t so obvious here is that this involves four round trips to the database, one for each set of data, plus some wonky lazy loading I couldn’t figure out:


We could alter the original query to eagerly fetch with left outer joins those other two items, but that could seriously increase the amount of data we have returned. Since I’m only interested one instructor/course at a time here, I don’t really want to pull back all courses and enrollees.

There’s a bigger issue here too – I’m passing around a live queryable around, making it possible to modify, iterate and otherwise make a general mess of things.  Additionally, I pull back live entities and all entity data – again, more inefficient the wider and larger my tables become. Since the entities could be live, tracked entities, I’d want to be careful not to modify my entities on the way to the view for reading purposes.

Ideally, I’d hit the database exactly once for only the data I need, and nothing more. This is what I often see people create stored procedures for – building up the exact resultset you need at the database level, only getting what we need. First, let’s pull in AutoMapper and create a ViewModel that represents our projected data:

public class InstructorIndexData
    public IEnumerable<InstructorModel> Instructors { get; set; }
    public IEnumerable<CourseModel> Courses { get; set; }
    public IEnumerable<EnrollmentModel> Enrollments { get; set; }

    public class InstructorModel
        public int ID { get; set; }

        [Display(Name = "Last Name")]
        public string LastName { get; set; }
        [Display(Name = "First Name")]
        public string FirstMidName { get; set; }

        [DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
        [Display(Name = "Hire Date")]
        public DateTime HireDate { get; set; }

        public string OfficeAssignmentLocation { get; set; }

        public IEnumerable<InstructorCourseModel> Courses { get; set; } 

    public class InstructorCourseModel
        public int CourseID { get; set; }
        public string Title { get; set; }

    public class CourseModel
        public int CourseID { get; set; }
        public string Title { get; set; }
        public string DepartmentName { get; set; }

    public class EnrollmentModel
        [DisplayFormat(NullDisplayText = "No grade")]
        public Grade? Grade { get; set; }
        public string StudentLastName { get; set; }
        public string StudentFirstMidName { get; set; }
        public string StudentFullName
                return StudentLastName + ", " + StudentFirstMidName;

We can flatten many members out (Department.Name to DepartmentName). Next, let’s modify our controller action to project with LINQ and AutoMapper:

public ActionResult Index(int? id, int? courseID)
    var viewModel = new InstructorIndexData();

    viewModel.Instructors = db.Instructors
        .OrderBy(i => i.LastName)

    if (id != null)
        ViewBag.InstructorID = id.Value;
        viewModel.Courses = db.Instructors
            .Where(i => i.ID == id)
            .SelectMany(i => i.Courses)

    if (courseID != null)
        ViewBag.CourseID = courseID.Value;
        viewModel.Enrollments = db.Enrollments
            .Where(x => x.CourseID == courseID)

    return View(viewModel);

Finally, we’ll need to configure AutoMapper to build mapping definitions for these types:

Mapper.Initialize(cfg =>
    cfg.CreateMap<Instructor, InstructorIndexData.InstructorModel>();
    cfg.CreateMap<Course, InstructorIndexData.InstructorCourseModel>();
    cfg.CreateMap<Course, InstructorIndexData.CourseModel>();
    cfg.CreateMap<Enrollment, InstructorIndexData.EnrollmentModel>();

With these changes, our SQL has improved (somewhat) in reducing the data returned to only what I have in my view models:

exec sp_executesql N'SELECT 
    [Extent1].[CourseID] AS [CourseID], 
    [Extent1].[Grade] AS [Grade], 
    [Extent2].[LastName] AS [LastName], 
    [Extent3].[FirstName] AS [FirstName]
    FROM   [dbo].[Enrollment] AS [Extent1]
    LEFT OUTER JOIN [dbo].[Person] AS [Extent2] ON ([Extent2].[Discriminator] = N''Student'') AND ([Extent1].[StudentID] = [Extent2].[ID])
    LEFT OUTER JOIN [dbo].[Person] AS [Extent3] ON ([Extent3].[Discriminator] = N''Student'') AND ([Extent1].[StudentID] = [Extent3].[ID])
    WHERE [Extent1].[CourseID] = @p__linq__0',N'@p__linq__0 int',@p__linq__0=2042

We’re now only selecting the columns back that we’re interested in. I’m not an EF expert, so this is about as good as it gets, SQL-wise. EF does however recognize we’re using navigation properties, and will alter the SQL accordingly with joins.

We’re still issuing three different queries to the server, how can we get them all back at once? We can do this with Future queries, an extension to EF that allows us to gather up multiple queries and execute them all when the first executes. Pulling in the “EntityFramework.Extended” NuGet package, we only need to add “Future” to our LINQ methods in our controller:

public ActionResult Index(int? id, int? courseID)
    var instructors = db.Instructors
        .OrderBy(i => i.LastName)

    var courses = Enumerable.Empty<InstructorIndexData.CourseModel>();
    var enrollments = Enumerable.Empty<InstructorIndexData.EnrollmentModel>();

    if (id != null)
        ViewBag.InstructorID = id.Value;
        courses = db.Instructors
            .Where(i => i.ID == id)
            .SelectMany(i => i.Courses)

    if (courseID != null)
        ViewBag.CourseID = courseID.Value;
        enrollments = db.Enrollments
            .Where(x => x.CourseID == courseID)

    var viewModel = new InstructorIndexData
        Instructors = instructors.ToList(),
        Courses = courses.ToList(),
        Enrollments = enrollments.ToList()

    return View(viewModel);

Which results in all 3 queries getting sent at once to the server in one call:


One other modification I made is I ensured that all projection occurred within the controller action, by calling “ToList” on all the IQueryable/FutureQuery objects. I’d rather not have the view be able to modify the query or otherwise introduce any potential problems.

Now, the SQL generated is…interesting to say the least, but that’s not something I can control here. What has improved is I’m now only returning exactly the data I want, into objects that aren’t tracked by Entity Framework (and thus can’t be accidentally modified and updated through change tracking), and all my data is transferred in exactly one database command. I intentionally left the model/mapping alone so that it was a simple conversion, but I would likely go further to make sure the manner in which I’m querying is as efficient as possible.

AutoMapper’s auto-projection of LINQ queries plus Entity Framework’s FutureQuery extensions lets me be as efficient as possible in querying with LINQ, without resorting to stored procedures.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Keynote slides from my Passion for Projects keynote

Henrik Kniberg's blog - Tue, 03/11/2014 - 19:46

Here are the slides for my Passion for Projects keynote Spotify – the unproject culture (+ failure story “How to burn €1 billion”).

So, now I’ve spent 2 days with 600 projects managers at a PMI conference. Totally different from the usual crowds I hang out with. Fascinating to hear stories about project management successes and failures in all kinds of industries – from warzone reconstruction projects to eurovision song contest.

I was a bit nervous (OK more than a bit) getting up at the biggest-ever scandinavian gathering of project managers – and illustrating to them how the standard project model really doesn’t fit well for IT product development, and how companies like Spotify actually don’t have PMs and don’t do projects (at least not the type defined by PMI)

I was happily surprised though. Instead of getting attacked for it, scores of PMs came up to me, agreeing with me, sharing similar experiences, and inspired to try agile principles in their own projects and industries.

And biggest positive surprise of all – the final keynote by Dr. Harold Kerzner, major thought leader in PM space who has written over 50 college textbooks on project management! He listed like 30 things that are wrong with traditional project management as tought in PMI textbooks, and where it all is heading in the future. He described it as a fundamental paradigm shift from PM 1.0 to PM 2.0.

According to Dr Kerzner, agile values and methods like Scrum are examples of the future of project management, and I was positively surprised at how well his description of PM 2.0 rhymed with agile values.

So what I saw was convergence – experts and practitioners arriving at the same conclusions, coming from lots of different directions. A magical feeling.

I’ve suspected it before, but talking to all these experts has made it clear to me – agile is a universal thing, way beyond just software.

I’m so glad I took the courage to get out of my comfort zone and meet these people. I wish more agile trainers and coaches would get out of the echo-chamber of agile conferences and see what’s going on in the wider world :)

(some sample slides from my talk below)



Project model

release must be easy


Categories: Blogs

Tricking customers

Clarke Ching - More Chilli Please - Tue, 03/11/2014 - 19:24

Many years ago I worked with a credit card company.  One of things we tried to do was create features which sounded useful (such as a “payment holiday”) but were really just ways of tricking people into not paying off their monthly balance in full so we could charge them interest.  I was a programmer, not a marketing person, so although I found it icky I could at least plead that I was only following orders.  Hmmm.

In the last couple of years I’ve set up 2 new credit cards.  One was through, the other through John Lewis.  Both are brands I love and respect.  Ooops, I mean LOVED and RESPECTED.  

Their problem is that they outsource the running of the credit card system and, by doing so, they dirty their own brand with the practices of the credit card company they use.  On both occassions, I’ve been “tricked” into missing my first payment.  Either that, or I’m stupid.  

I don’t think I’m stupid.  

On both occasions, I filled out a lot of paperwork (Obfuscation anyone?) and I thought at the end I’d set the accounts up to take my payments out automatically.  It turned out that I hadn’t and I had to make manual payments.  Stupid me.  


Amazon’s credit-card provider charged me a 50 pound late-payment fee. I haven’t trusted amazon since - even though it was their provider that pooped on me.

Sorry for the rant.

Categories: Blogs

Stupid computer people

Clarke Ching - More Chilli Please - Tue, 03/11/2014 - 19:13

I recently got myself a new credit card and it seems that the people who designed the security system don’t have a clue about how people work.

I now have 4 different things I have to remember (or write down) when I want to interact with them

  • A unique - and unmemorable - login which they give me.  (What’s wrong with my email address?)
  • A password I was allowed to choose (but had daft rules so I had to store it in 1password - which is probably a good thing).
  • A special word I use when I call them.   
  • A special number I use online - which is 5 digits long.

I can’t remember any of these and it makes me flustered and angry when I interact with them.  I don’t consider myself stupid, but dealing with them makes me wonder if I am.

Last week I tried to make an online payment and I couldn’t do it because it required my "special online number" and I not only had I forgotten my "special online number" I had forgotten I had a "special online number".  It’s so special I forgot it!  So I couldn’t make my payment … and I was overseas … and so I had to stop using their card and switch to another.  Arggggh.


I know it’s not easy creating secure systems which are easy to do, but some companies do it well.  Others, rather than copying the clever guys, invent their own ways.  


Apologies for venting.

Categories: Blogs

Satya Nadella on How the Key To Longevity is To Be a Learning Organization

J.D. Meier's Blog - Tue, 03/11/2014 - 17:30

Everything should be a startup.

Unless you’re a learning organization that actually uses what you learn to leapfrog ahead.

But the paradox is you can’t hold on too tightly to what you’ve learned in the past.  You have to be able to let things go.  Quickly.  And, you have to learn new things fast.  And, if you can create a learning organization with tight feedback loops, that’s the key to longevity.

Adapt or die.

But the typical challenge in a big organization, is rejecting the new, and embracing the old.   And that’s how the giants, the mighty fall.

Here is how Satya Nadella told us how to think about what longevity means in our business

“What does longevity mean in this business? Longevity in this business means, that you somehow take the core competency you have but start learning how to express it in different forms.

And that to me is the core strength.

It's not the manifestation in one product generation, or in one specific feature, or what have you, but if you culturally, right, if you sort of look at what excites me from an organizational capacity building, ... it's that learning ... the ability to be able to learn new things ... and have those new things actually accrue to what we have done in the past ...  or what we have done in the past accrues to new learnings ... and that feedback cycle is the only way I can see scale mattering in this business ... otherwise, quite frankly you would say, everything should be a startup ... everything should be a startup ... you would have a success, you would unwind, and everything should be a startup ... and if you're going to have a large organization, it better be a learning organization that knows how to take all the learning that it's had today and make it relevant in the future knowing that you'll have to unlearn everything, and that's the paradox of this business and I think that's what I want us to be going for.”

In my experience, if you don’t know where to start, a great place to start is get feedback.  If you don’t know who to get feedback from, then ask yourself, your organization, who do you serve?   Ask the customers or clients that you serve.

But balance what you learn with vision.  And balance it with analytics and insight on behaviors and actions.   Customers, and people in general, can say one thing, but do another, or ask for one thing, but mean something entirely different. 

Remember the words of Henry Ford:

“If I'd asked customers what they wanted, they would have said ‘a faster horse’.”

Expressing pains, needs, opportunities, and desired outcomes leaves a lot of room for interpretation.

Drive with vision, build better feedback loops, interpret well, and learn well, to survive and thrive in an ever-changing world.

You Might Also Like

Microsoft Explained: Making Sense of the Microsoft Platform Story

Satya Nadella is the New Microsoft CEO

Satya Nadella is All About Customer Focus, Employee Engagement, and Changing the World

Satya Nadella on How Success is a Mental Game

Satya Nadella on Live and Work a Meaningful Life

Satya Nadella on the Future is Software

Satya Nadella on Everyone Has to Be a Leader

Categories: Blogs

A Conference Call in Real Life (youtube)

I’ve started to show this video in my public CSM classes (see sidebar for scheduled courses) as part of the discussion about why co-location for Agile teams is so important.  The video is a humorous look at what conference calls are like.  Probably the most notable part of it is the fact that on a conference call you can’t see people’s body language and facial language which are important cues for efficient communication:

Please share!
Categories: Blogs

Testing WebHooks With

Derick Bailey - new ThoughtStream - Tue, 03/11/2014 - 14:00

SignalLeaf uses for billing. One of the cool things it does is provide web hooks to get events so that you can have your system do things in response to those events. Examples of events include customer creation, customer subscription changes, charges being made to a customer, charges failing, and a whole lot more. 

I find myself needing to use these webhooks (well, ok… I needed to be using them 6 months ago, but I’m here now and I’m finally getting it done) and began wondering how I could get sample data and sample requests – not just documentation or “Events & Webhooks” list on the Stripe site. I want to see the actual request headers, body and payload of the request as a web server will see it. Call me paranoid… I just don’t trust documentation and logs all that much – even from a company that I trust with my business. 

Enter, – an epic little service from Runscope that lets me set up a sandbox URL to receive HTTP requests and log all the pretty details that I want to see. 

Setting Up The Bin

To get stripe integration working, you need to create a bin first. Hit the site and click the big button


I checked “private” for mine, cause I don’t want anyone else to be able to see the data. Once you have the bin created, you’ll see this nice big page with your URL and a ton of examples plastered all over it.


Copy the URL out of that box and then head over to your account.

Set Up Your Web Hooks

Open your account preferences, and click on the Webhooks tab.


Click the “Add URL” button in the bottom right. Add your bin’s URL.


Since you’re interested in testing the web hooks to get access to the real data, make sure the “Mode” is set to test. Click the “Create” button when you’re done and it will show up in the list of webhooks.


Test It

Now that you have it configured, you can do some testing. Set up subscriptions, test customers and all that jazz. For me, I had a bunch of test customers in my test mode already. So I just went in and invoiced one of them that had a subscription. Be sure you’re in test mode, first.


After you do some stuff with a sample account and subscription or whatever else, hit refresh on the and you’ll see all the beautiful details of the request!


From there, you can save the request details and use that as an example to build your code.

But Wait! There’s More!

Of course that isn’t all that Runscope can do – is only one tool that it provides as a service. Be sure to check out the rest of Runscope including what John Sheehan calls the “super-charged version” of request-capture.

@derickbailey you should try the super-charged version:

— John Sheehan (@johnsheehan) March 3, 2014

Runscope seems like something that will be a regular part of my toolbox in the near future.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Product Vision Tools Part 1: The Product Vision Board

Leading Agile - Mike Cottmeyer - Tue, 03/11/2014 - 13:52
Creating a Clear Product Vision

Product vision is super important to the success of your product. I know, its just a simple statement, right? How much impact can it really have? More than you can imagine. A product vision gives us the direction and focus we need to deliver something, anything, that will ultimately solve the problems of a customer segment and deliver value to both your business and to your customer. If it is well-crafted and well-communicated, product vision should permeate everything you do, from business models and product roadmaps to the stories in your backlog and how you execute them.

Here’s a test for you. Take a minute and scribble down the vision statement for the product you’re currently work on. Now here’s another test. Have the co-workers who sit near you do the same without discussing it. Compare notes. Do your notes match? Are some notes still blank? Are any of the notes the same? Do the same test across your organization. If your notes match, you can stop reading now…well, not really, but you obviously work on a product with a clear vision. If you have blank notes or notes that vary widely, read on.

Test number two. When you finally find your product’s vision statement on the company website or wiki, how does it read to you? Is it delusional? Cloudy? Confusing? Dismissive? Heady? Wordy? Lengthy? Boring? Uninspiring? Generic? Maybe a little of all of those.

Don’t feel bad. Some of the best organizations in the world have difficulty using words to define what it is they do, who it is they serve, and what success looks like to them. You are NOT alone, trust me. But you don’t have to wallow in the words of your vision statement much longer. There are some very simple tools that can help you clearly define your product and use it to drive your product’s business model, your product roadmaps, your product-market fit experiments, and your backlogs for your teams. In this post and posts to follow, we’ll introduce several of these tools and discuss how they can help you create a vision that resonates with customers and the people who you work with, and help you constantly align the work you do with the vision you have created.

Defining Your Initial Product Vision

When most organizations develop their vision statements, they default to some standard template. One of the more popular templates comes from Geoffrey Moore. While I love Geoffrey Moore and consider him a mentor, I think his traditional vision template leads to rather unexceptional vision statements that all sound the same: “For blah blah blah customer who needs blah blah blah, our blah product is a blah blah blah that will blah blah blah. Unlike our competitors (insert list of competitors that are usually not competitors) our product blah blah blah blah blah…”

You’ve heard vision statements like this before. Somehow, they hit all the right points, but more often than not, every time I see this template used, the vision statement gets very long winded and all I can hear is “blah, blah, blah…

What I’d rather have is a simple, concise, visual representation of the vision that I can understand and relate to. I’d rather see an inspiring overarching vision that I can get excited about and say “Yes! That’s where I want to go!”. I’d like some detail too…about who it is we’re building for, what problems they have, and how our idea solves that problem. I might even want some info on how our company gets value from what we build, but really I’m more interested in who we are addressing and what their problems are.

Enter Roman Pichler’s super simple Product Vision Board. It’s the tool I turn to most often when I start working with teams to define their product vision. It simple, concise, AND visual. Check it out:

Vision Statement

Let’s walk through the sections and see what we need to think about.

Steps to Create a Product Vision

First, we need to craft a vision statement. Here’s some simple advice on what to write in this box: Say a lot in just a few words. Pick your words wisely. Don’t be generic. Describe a long-term vision but don’t be overly restrictive. Clear, concise. Calls people to action. Oh, and if you took the two tests above with your co-workers, they’d all remember it…or at least a pretty close flavor of it.

Need some examples? Try something like Innocent Drinks’ vision statement: “Make natural, delicious food and drink that helps people live well and die old. Too simple for you? Want something a little more “corporate”? Here is Ikea’s: “To create a better everyday life for the many people, we shall offer a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.” A little wordy for me, but it does get the point across.

After you’ve wordsmithed your awesome, clear, thoughtful, inspiring vision statement (and if you have, share it here, I’d love to read them), write it in the box, pat yourself on the back, high-five your teammates, and move forward one space.

The next four boxes should be easier. Mostly because they are all hypotheses, or guesses at what you think the right answer is. The first box “Target Group” is all about our customer hypothesis. Who do we believe we are trying to serve? Typically, for a new product, or even existing products, we’re looking at the earlyvangelists. We’re looking for customers who clearly identify with our vision. Notice I did say our solution? We want customers who to buy into our vision. They fall in love with the idea, not the solution. So try that out and see if turns out to be different than the customers you currently view as your target segment. Got it? Good, write one sentence in the box that simply describes these people, pat yourself on the back, high-five your teammates, and move forward one space.

The next box, “Needs”, addresses our problem hypothesis. What do we think the problems of our customers are? Again, don’t fit the problem to your solution. Empathize with your customers and truly try to understand what their problem is. Not what you want it to be. When you think you have a good problem hypothesis, write it in the box in clear, simple terms, pat yourself on the back, high-five your teammates, and move forward one space.

Box number four: “Product”. This is your solution hypothesis. Based on the customers you described, and the problem you identified, what is the minimal thing you can do/build to solve that problem and make them smile? Again, this isn’t rocket science. It’s a guess.  First guess. It doesn’t have to be right. It just has to be something you can build, test, and see if your customers smile. Got it? Awesome! Write it in the box in clear, simple terms, pat yourself on the back, high-five your teammates, and move forward one space. You are nearing the end of this game.

Last box: “Value”. This box vexes me a bit and to be honest, I don’t usually fill it in the first time around. So first timers, leave it blank. It’s OK. The world will not end if you do not define the value to your business right now. Why? Because so far, the other boxes have been guesses. Hypotheses need to be tested, validated. Chances are very high that the things you wrote in those boxes will change as soon as you start using the tool we’ll be covering in our next post, the Validation Board.

So for now, feel good that you’ve defined an initial product vision and you are ready to start testing in the real world. Pat yourself on the back, high-five your teammates and grab a beer…or maybe one of Innocent Drinks’ product, they might make you live well and die old.

For specific information on designing teams check out Product Owner Team Design Considerations.



The post Product Vision Tools Part 1: The Product Vision Board appeared first on LeadingAgile.

Categories: Blogs

Refactoring Rails Legacy Apps with APIs and Messages

TV Agile - Mon, 03/10/2014 - 20:47
Ruby Rails as a framework is famous for getting an application up and running quickly, but the very paradigms that make it so easy at the start can lead to maintenance nightmares down the road. Successful applications grow rapidly larger, more complex, and harder to extend and maintain. One way to approach refactoring a monolithic […]
Categories: Blogs

It’s MAD to Have a Separate Discovery Team

Constant Change - Aaron Sanders - Mon, 03/10/2014 - 16:15

Diving deeper into the first item on the list of Misadventures of Agile Discovery (MAD), let’s look into the problem of having a separate discovery team. Let me start with a couple of stories. Outsourcing the work Before I started working with a client, the mobile division hired an outside vendor for user research. After I […]

The post It’s MAD to Have a Separate Discovery Team appeared first on Constantly Changing.

Categories: Blogs

Solving the Social Media Challenge

Scrum Breakfast - Mon, 03/10/2014 - 16:09
Delight the customer. Inspect and adapt. I've been teaching that for years. And I have been working on eebee, a feedback solution, to help anyone who holds events to get more and better feedback from their participants. 
Then I got an email from a hotel director I stayed at. "If you liked us, click here to tell TripAdvisor. If not, click here to tell me." 
Boy, what a decision! He has no idea if I'm happy or not, but an immortal comment on the Social Media is just one click away! Feedback is about more than listening to the customer, it's about guiding the conversation, before it goes viral! Steve Holyer and I made a video, to explain the problem:

Does this resonate with you?
Categories: Blogs