ALM Summit: Day Two

Wow, day two is in the books… where to start?  Well, maybe I’ll start at the end:  Free beer and buffet for over 3 hours definitely provided a nice finish to the end of the day.  I didn’t network the way I imagine I was probably supposed to: milling around the room and trying to make contacts.  Instead, I sat with two great guys (both from Canada) in a booth and talked about stuff while we drank and ate for several hours.  Enough about that, though, what about the sessions?

Continuous Delivery

Brian Harry’s keynote continued the Continuous Delivery theme that seemed to be running through quite a few sessions, including showing how Microsoft changed around its own process to go from shipping boxed software every two years to service updates every 3 weeks.  Along with this change, there have also been a lot of tooling changes that have happened in the Microsoft world to support this model, though most seemed to be “catching up” types of features.

Work Item tagging, now in Update 2 CTP 2, seemed to really stand out to me as something I could use.  We use a concept of Themes on stories which helps us relate things back to a Road Map and a Release Plan.  Being able to filter and group by tags on Themes would really help us a lot in easily seeing the weighting we have in the backlog for different themes.

The other tooling change in the Team Foundation Service (TF Service) was about Web Test Case Management (TCM).  Next to the ‘Build’ tab on TF Service, you’’ll now have a Test tab that will let you use a web portal to manage your test case execution and definition, much like using Test Manager locally on your box.  This seemed to really be useful when working on different devices and not wanting to install Test Manager over and over again.

I hadn’t seen the Kanban board before, and it definitely looks like something I need to investigate.  The WIP limits and easily customizable columns probably lend themselves easily to our projects that need a more lean approach, but still have heavy tooling in the back-end like Team Foundation.

Probably the biggest news of the day was the announcement that Git support was available.  Not an MS flavour of Git, but true full Git support.  I don’t personally use Git, but I’ve talked to enough folks about it to know that this is what was needed to get Microsoft past the DVCS hurdle.  Now you can’t say that you won’t use Team Foundation as an ALM tool because you don’t like the source control.  Microsoft eliminated that from the equation 🙂

Agile Under a Waterfall

I don’t know what it is about the morning sessions, maybe I’m still awake enough, but I’m getting great value out of these.  Ben Day made a fantastic presentation on how to make Agile work when dealing with Waterfall organizations.  He made some great points on a number of topics, but I think the following was the most impactful one for me:  acknowledge that change takes time.

It is so important that we understand that just because we think we are right, that doesn’t mean that everybody is going to agree with us right away and that we’ll all be working the same way in harmony tomorrow.  We need to see why both sides want what they want and lead the transition towards the desired end goal.

I was planning on writing up a long summary of Ben’s points, but he put up his presentation for download.  Ben’s table on the Comparisons and Motivations of Waterfall and Scrum really let us start asking the question of “Why”.  Why is Waterfall being used?  Why do we want to do Scrum instead?  Why does each side think the other is nuts?

I’ll close out this session summary with a few quotes that really capture how great this session was:

• “You can drive with your feet.  It doesn’t mean it’s a good idea.”
• “You don’t have on TV, weather committers”.  Say forecast”!
• “SUW is the grumpy marriage of two processes.  I hate you and can’t wait until you drop dead.”
• “This is like a loaded hand-gun in a daycare center” (regarding using the burndown chart for Evil)
• “Your developers are afraid of you.  Your middle managers are afraid of you and your developers.” (on Leadership and dealing with the fact that Fear is Everywhere)

Load Testing in the Cloud

I attended this session, but didn’t get engaged.  From what I could gather, there are some really neat ways to spin up environments to support dynamically load testing different scenarios.  This was another session in the “Continuous Delivery” vein, but I think I missed out on the real value here.  Maybe it’s because I don’t need to worry about load testing my projects in a geographic dispersion with multiple instances, but I did understand the basic benefit:  stop buying all this hardware to load test at the end of the project.  You can spin that up as you need it, and then shut it down when you’re done.  This also lets you keep doing it more often, and not just waiting for the end of the project to load test.

The Know & Do Era

James Whittaker delivered a keynote today on the last few technical eras, starting in the 90’s, and described where he believes our industry is going over the next 10 years.  James is a very engaged orator, and knows how to wow you with his vision.

The eras are basically broken down as this:

1. 1990’s: Store & Compute.  For example, the Human Genome Project
2. 2000’s: Search and Browse.  Google your Bing.
3. 2010’s: Know & Do.

From James’ session, his opinion is that we are moving away from looking for stuff via digging through search results and into receiving information handed to us based on what the system already knows.  Know & Do is putting Data and Experiences together  to achieve optimum conversion of your consumer.  Experiences are what we want, not data mining expeditions.  We don’t all want to be data scientists combing the big data using Ask Jeeves to figure out where the closest restaurant is that has the best pizza.

James provided a good example regarding vacations.  If you want to take a vacation, why are you checking your calendar for a good time to be gone, then going through a dozen websites to find hotels, cars, events, food, etc., and then going back to the calendar to plot it all in.  Why can’t we stay in the calendar?  Why can’t the data come to us?  Why can’t folks who know the most about data (hyper-local data) surface up these details to us based on our location (or desired location)?

I walked out of this session thinking I needed to build something fast.  I didn’t know what, but I wanted to do it.  James definitely knows how to fire up a crowd!

Specification-By-Example

How do we capture use cases when acceptance criteria are so generic and not full specs? Christian Hassa addressed this and other topics before taking the group into specflow, a tool that seems to allow for business rules to be evaluated regardless of the way they are executed.  Personally, I think I need to look at specflow and MS Test Manager some more and see what overlaps and gaps exist between these two tools before I can know what each of the tools can give me, but most of the session was very much about a few simple truths we should all follow for doing Agile requirements:

1. Acceptance Criteria are fine, but examples will give us the ability to document what we expect in different scenarios.
2. Conversation and Collaboration needs to occur to ensure the 3 Amigos all understand what needs to happen.

Birds of a Feather – Liftoff

I sat down with Diana Larsen and some other great folks during the BoFs and chatted about how to get projects off the ground, how to get teams started, and how to get folks into the concepts quickly and accurately.  I shared a lot of experiences that I’ve had with doing this, and what seems to be common across the consulting world is that chartering is the way to go:

1. Sit down together for some period of time.
2. Figure out how you’ll work together.
3. Figure out at a high level what you are supposed to do.
4. Look for gaps in the team and what we think we need to do.

There were really two big things I came away from my talks that I want to look into:

1. Retrospective during the charter
   We informally gather team knowledge about what has worked or not worked in the past when we figure out our charter, but by running an actual retrospective about past projects during liftoff we get the same info, but TEACH how to do a retrospective at the same time.
2. Mini-sprints in Sprint 0
   It was generally held at the conference that it takes about 4 sprints before you know what you’re doing. 
   1. The first time you either fail miserably because you don’t know what you’re doing, or you succeed well because you’re so afraid of the unknown that you under-commit. 
   2. The second sprint you react to sprint one and usually get a result that is completely unplanned for. 
   3. Now, the team thinks they have figured out what they did wrong, but need to get through Sprint 3 of trying to do it right and this is touch-and-go as to whether the sprint 3 will be successful.  Something usually goes wrong in here that triggers a final re-adjustment.
   4. We now know what is right, what is wrong, and how to do the right thing.  We finally run things the right way from start to finish.

The concept brought up was to run mini-sprints inside of the Sprint 0 to get these 4 out of the way.  By doing 2 or 3-day sprints, the team can run the kinks out of the system by rapidly defining the next steps for Sprint 0, planning, prioritizing, and then finally executing and reviewing how things went.

The thought was that by doing these mini-sprints, the team won’t need four sprints to figure it out, since they’ll already have done that by now.

What is value?

This last session confused me a little.  I thought it was going to be about how to determine value, but Jez Humble seemed to be trying to get us to recognize that measuring value is what is important, even over normal Product Owner type of activities.  The “how” didn’t matter, what mattered was that we needed to start measuring.

Lean came up a lot, probably from the idea of quick prototyping and getting the minimum viable product out and working.  The main concept that seemed to permeate throughout the session was this:

Hypothesis-driven delivery

• We believe that [building this feature] [for these people] will achieve [this outcome]
• We will know we are successful when we see this signal from the market

We need to teach others how to experiment, and then optimize ourselves for experimentation.  I think this applies really well to Lean Startups, or other new products that are just trying to get out there right now.

We also need to walk away today asking ourselves what we are passionate about:

• If you knew success was guaranteed, and you could do anything without risk of failure. what would you do?

What would you do?