Internal Customer Service and What I’m Doing to Be Agile

I’ve been spending a lot of time in the last six months retreading myself in Agile as we are rolling out Agile to several organizations. During this process, we’ve talked with our internal developers a lot about the Agile Manifesto and the Principles Behind the Manifesto. As we share these principle with our team, I’m finding it very healthy for myself to go back to these basics which are so easily forgotten or inadvertently pushed aside.

As a refresher The Agile Manifesto reads:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

And, what I believe to be the most important principle from the 12 principles behind the manifesto:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

In looking back in my nearly ~10 years of “being Agile” I’m ashamed to admit that I’ve never really sought out the customer to find out how I, or my team, was doing. I’ve likely asked casually how things are going in an ad hoc fashion, but I’ve never taken deliberate and disciplined steps to checking in with my customers.

In our current Agile adoption we changed that, and my encouragement is that you to consider doing the same if you’ve lost sight of your customer. We built a simple survey (takes only 90 seconds to fill it out) to inquire how we’re doing. We initially circulated the questionnaire on a monthly basis and then backed off to quarterly which gives us a regular cadence on getting empirical feedback.

Here are the questions we ask to ~20 key stakeholders of our development process and software:

Q1. How eager were the representatives of our department to help?
Q2. When discussing project requirements, how satisfied are you with the interaction with the team?
Q3. How satisfied are you with the communication of project status during the entire process?
Q4. Would you say that our team solved your problem or answered your question quickly, slowly, or neither?
Q5. How well did the output from the team meet your business objectives/needs?
Q6. How knowledgeable did our team representative(s) seem to you?
Q7. How clear was the information that our representative provided to you?
Q8. Overall, are you satisfied with the service you received, dissatisfied with our service, or neither satisfied nor dissatisfied?

Open Ended Questions

Q9 (Optional): What’s the most recent example of how we have exceeded your expectations on this project?
Q10 (Optional): Is there a recent example where we have not met your expectations?
Q11 (Optional): What is one thing none of devs do but wish we would?
Q12 (Optional): Additional comments?

When I push these surveys out I anxiously await the results to see how we’re doing.I review each one personally. I’ll be frank, it has been a mixed bag of emotions. Sometimes (read:often) what I read isn’t easy to read; while we have drastically improved internal customer service, our stakeholders ask for more (and rightly so).

In the past, I may have been too quick to use the Agile manifesto and underlying principles selfishly for my own gain when it suits me and when it plays to my advantage in furthering my cause. As of late, I’m challenging myself and the team to continue to refer to the manifesto and it’s underlying state-of-mind/ethos, especially as it relates to the human side of development (customer satisfaction, changing requirements, working together, and communication).

As you head into the week, consider your own situation, might you be able to adhere to the Agile principles just a bit better? The survey is what is working for us and it may or may not work for you. If you desire, please feel free to copy and use the questions we’ve used (we picked them very carefully).

I’m curious…what do you think? How could/should we be more “Agile”. Please post your thoughts, suggestions, and results of your own survey’s in the comments below.

Posted in Agile | Leave a comment

How Google broke the OSS compact with Angular 2.0

When I first wrote the title, I had to pause for a moment to consider if I was actually writing this post or if it was a bad dream. As it turns out, at least from my vantage point, what I’ve seen thus far, which candidly isn’t that much, has been much like a bad dream. For purposes of this post, what matters more is what we know we haven’t seen. Nonetheless, I have seen enough to make a few conclusions I’ll express here.

It’s helpful to start with some defined terms and a framework that I can use as a backdrop to support my argument. In this case, I’m relying on the classic OSS development model described by Eric Raymond in his 1997 essay The Cathedral and the Bazaar. I won’t go into all of the model’s facets save one: That all users should be treated as co-developers. The over-arching theme of OSS is one of transparency and at least get as close as possible, to true democratization.

In reality though,democratization is often preached by the same people that just as often don’t practice it. I won’t delve into motive or intent. Rather, I’ll simply rely on what I’ve seen and observed as an outsider looking at the building that has its curtains drawn – trying to get a glimpse of what is going on inside. Is it my or any of our business? You bet it is as collectively, we are part of a large community that is responsible for Angular’s success. We are impacted by decisions being made in the dark.

Looking at Angular 1.x, it has quickly become one of, if not the most popular MV* web development frameworks today. There is a robust community and at last count, has over 1000 contributors. All one has to do is navigate to to see how robust and vibrant the community is.By all accounts, the Angular Team appreciates this community through the comments expressed at the 2014 ng-Europe Conference. In this day and age, words don’t mean nearly as much as actions. I’m a member of that ever-growing legion of people that judges by what is done, not what is said.

There is no doubt the external community (those outside Google) is the reason why Angular has been so successful. It’s common sense after all. Without broad uptake and support, an OSS Project may be many things, but a success won’t be one of them, unless of course, the goal was for the software to only be used by a few people.

Today, the world is abuzz with mentions of Angular 2.0. Here and there are mentions and perhaps the briefest of glimpses of what 2.0 will be. We keep hearing that it’s not an upgrade, but a complete rewrite, that it is for modern browsers, support for ECMA 6, etc. We’ve heard they seek to make 2.0 more modular and to correct things that weren’t right in 1.x. It all sounds good. But my question is simply this “Where is it? Perhaps you are part of an enterprise that adopted Angular and are wondering what the future will hold. What will happen with 1.x support? Should you plan for an upgrade? Can you upgrade? What about the supposed lack of support for certain browsers? Can you test and verify that? What are the plans after the first release? Again, where are the bits? This is one of the first blog posts on the matter: Note the date – March, 2014. You’ll soon see how common that date is.

As it turns out, there were some resources where we could start to get a picture. The problem is, that momentum never carried though. One such site is the learn Angular site: Note the date: March, 2014. This is nearly an 8 month old post. Supposedly, the design documents are kept on a Google Drive: There was much hype about the designs being released: Note the date – March 2014. After that, there has been for the most part, radio silence until the ng-Europe conference. But even at the conference, there still wasn’t much in the way of meaningful details. Looking at the documents today, they are either out of date or completely unreadable. Many have been crossed-out entirely. What does this mean? Has that design been scrapped? Is it a bad edit? If there is meaningful information in either the doc library or the source repos, then it is like finding a needle in a haystack. If the goal was to achieve secrecy through obfuscation, then congratulations – mission accomplished. It would be fair for some to conclude that Angular 2.0 is mere vaporware. I’m not willing to go quite that far.

Here’s my contention: if all of this was around the first release of Angular, fine. We had nothing in the first place and the team is trying to get things squared away before going public. I’ll say this, had this been Angular’s first release, where there was mis-communication and partial transparency, the prospects of success would not be there. The fact is, this IS NOT Angular’s first release. Clearly, 2.0 is a revolutionary step over 1.x. The Angular Team looking to capitalize and build upon Angular 1.x’s success. As such, the community that was praised at ng-Europe has a reasonable expectation to be kept in the loop. That’s the way you’re supposed to treat the community that makes up your development partner base. To me, it seems rather common-sensical. Why on Earth would a team want to disenfranchise the very community it relies upon and praises? Is it meaningful praise or does it just make for good copy? Words are cheap and easy. Again, it’s what you do that counts.

There’s an old saying in business and politics: You dance with the one that brought you…

If some other notable companies engaged in this sort of behavior, they would be publicly flogged. I’ll leave it to the reader to speculate on who those notable companies are.

My request of the Google Angular Team is a simple one – stop with the secrecy. Get the community involved. I’m not saying there has to be design by committee. That’s never a requirement in OSS. There should however, be an opportunity for the public to review and comment. Whether you implement that feedback is up to you. The public has a good way of showing its support or lack thereof. There are many individuals and organizations that not only need time to evaluate, they are owed that time. That is part of the compact. That’s how you earn and retain trust.

The public has put its collective trust in Angular. The Angular Team should return in kind.

Posted in OSS | 28 Comments

Chocolatey Now has Package Moderation

Well just after three years of having, we’ve finally implemented package moderation. It’s actually quite a huge step forward. This means that when packages are submitted, they will be reviewed and signed off by a moderator before they are allowed to show up and be used by the general public.

What This Means for You Package Consumers

  • Higher quality packages – we are working to ensure by the time a package is live, moderators have given feedback to maintainers and fixes have been added.
  • More appropriate packages – packages that are not really relevant to Chocolatey’s community feed will not be approved.
  • More trust – packages are now reviewed for safety and completeness by a small set of trusted moderators before they are live.
  • Reviewing existing packages – All pre-existing packages will be reviewed and duplicates will be phased out.
  • Not Reviewed Warning – Packages that are pre-existing that have not been reviewed will have a warning on Since this is considered temporary while we are working through moderation of older packages, we didn’t see a need to add a switch to existing choco.

Existing packages that have not been moderated yet will have a warning posted on the package page that looks like

This package was submitted prior to moderation and has not been approved. While it is likely safe for you, there is more risk involved.

Packages that have been moderated will have a nice message on the package page that looks like

This package was approved by moderator mwrock on 10/26/2014.

If the package is rejected, the maintainer will see a message, but no one else will see or be able to install the package.

You should also keep the following in mind:

  • We are not going to moderate prerelease versions of a package as they are not on the stable feed.
  • We are likely only moderating the current version of a package. If you feel older versions should be reviewed, please let us know through contact site admins on the package page.
  • Chocolatey is not going to give you any indication of whether a package is approved or not. We expect this to be temporary while we review all existing packages, so we didn’t see much benefit to the amount of work involved to bring it to the choco client in its current implementation.

What This Means for Package Maintainers

  • Guidelines – Please make sure you are following packages guidelines outlined at – this is how moderators will evaluate packages
  • Re-push same version – While a package is under review you can continually push up that same version with fixes
  • Email – Expect email communication for moderation – if your email is out of date or you never receive email from chocolatey, ensure it is not going to the spam folder. We will give up to two weeks before we reject a package  for non-responsive maintainers. It’s likely we will then review every version of that package as well.
  • Learning about new features – during moderation you may learn about new things you haven’t known before.
  • Pre-existing – We are going to be very generous for pre-existing packages. We will start communicating things that will need to be corrected the first time we accept a package, the second update will need to have those items corrected.
  • Push gives no indication of moderation – Choco vCurrent gives no indication that a package went under review. We are going to put out a point release with that message and a couple of small fixes.

Moderation Means a Long Term Future

We are making investments into the long term viability of Chocolatey. These improvements we are making are showing you that your support of the Chocolatey Kickstarter and the future of Chocolatey is a real thing. If you haven’t heard about the kickstarter yet, take a look at

Posted in chocolatey | Tagged | 20 Comments

Chocolatey Kickstarter–Help Me Take Chocolatey to the Next Level

I’m really excited to tell you about The Chocolatey Experience! We are taking Chocolatey to the next level and ensuring the longevity of the platform. But we can’t get there without your help! Please help me support Chocolatey and all of the improvements we need to make!

The Chocolatey Experience

Posted in chocolatey, Uncategorized | Tagged , | Leave a comment

Hypermedia hangout: Collection+JSON, HAL, and building .NET hypermedia APIs with Nancy and ASP.NET

Yes that title is a mouthful. Recently I had the pleasure of doing a google hangout with Jonathan Channon of Nancy fame and Phil Cleveland on a topic you’ve heard me be slightly passionate about, Hypermedia.

You can find the full hangout which was published on air here, which was recorded for your enjoyment and displeasure :-)

My reasoning for getting in the convo was a bit selfish. I maintain a library for Collection+JSON APIs (which I’ve never blogged about) which I want to be used with Nancy.

Originally the library was built strictly for ASP.NET Web API, however after getting feedback from Andreas, that I should decouple it so NancyFx users could use it. I took his advice and did that! I refactored into 3 packages two of which can easily be used in Nancy. However, no one is doing it. My hopeful result for this call with Jonathan is that would change as he is deep into Nancy and interested in Hypermedia. It looks like I reached that goal :-)

In the hangout we start off (well mostly I was talking) talking about Hypermedia itself and different formats, namely HAL and Collection+JSON. Then we went into looking at a few sample APIs (including out issue tracker example from the book) using Collection+JSON, my CJ library, as well as how to implement a hypermedia API / useful patterns. Along the way we also delved into Profiles and the role they play for hypermedia APIs. Finally we ended the discussion talking about what this means for Nancy and what we could do to enable CJ in Nancy. That led to the creation of this github project! Jonathan and I will be iterating the next few weeks on bringing CJ to a Nancy near you.

Let the hypermedia games begin!

Posted in collectionjson, HTTP, Hypermedia | 1 Comment