The conference is all done, and I’m finally home from Seattle wishing there was more, but also really wanting to get back into the office and share what I’ve learned.

I met some incredible people this week, and had some great conversations around the breakfast table, over beers, and in the hotel shuttle rides.  I am really going to miss that warm weather, even if it was always raining, because it’s some 20-30 degrees colder back at home right now.

Like the rest of the days, Day Three started with a breakfast followed by a keynote.  We were not disappointed…

Lean Startups, Cheezburger, and You

Scott Porad’s keynote on Lean startups was excellent, and really pointed out the differences between the startup model and the traditional operational model of an established business.  In a startup, you are living in a world of extreme uncertainty.  You don’t know what you are doing, or how you’re going to figure out how to do it.  This is where we need to get into rapid delivery so we can learn faster.

The Build-Measure-Learn (BML) loop was a big part of this keynote, and has been mentioned almost as many times as Dan Pink’s book at this conference.  Scott boiled it down for us:  If you only learn one thing, it’s to avoid building stuff nobody wants and get through the loop faster.  Everything else about BML is just commentary.

My impression has been that ‘Lean’ is perceived by those outside technology delivery (i.e. pointy-haired-bosses) to be a cheaper delivery model.  However, one of the comments made during this keynote supported my belief that this was wrong:  Lean is not cheap.  Instead, Lean is not wasteful!

We aren’t doing Agile because it’s cheaper.  We’re doing Agile so we don’t waste money rebuilding something that was built wrong in the first place.

Un-Managing Agile

Ever since I saw the video of the presentation by Aaron Bjork on Managing the Agile Process that he delivered at the last ALM Summit, I’ve wanted to see him do his thing live.  Unfortunately, I had to miss out on another great session that was running at the same time in the Kodiak room, but I was glad I stuck with my original plan and attended Aaron’s session because he really speaks to what I’m trying to do right now to be better.

Aaron likened what we need to do for our teams to what we do for our customers.  We need to setup a pit of success that is easy to fall into, and hard to fall out of.  Our teams need to have fun and want to do what they are doing.  So this comes down to us needing to focus less on Control, and more on Environment.  We need to get the Environment the team is working in to be fun, easy, and a place that will promote great work.

So this boils down to motivation, and of course that means we’re going to quote some Dan Pink:

1. Autonomy. 
2. Mastery.
3. Purpose.

Instead of letting our teams do what they want, get good at it, and buy into why we are doing it we often resort to standard carrot or stick methods to force an output.  Or we split their time across multiple projects, keeping them from Mastery.  Or we don’t explain what the goal of a feature is or what our customer is trying to do with what we are building.  That’s on the folks leading the team, not the team itself.  Aaron pointed to the classic example of Microsoft Encarta vs. Wikipedia.  One is backed by unlimited resources, awesome talent, and it falls to a bunch of folks doing it for free because it was fun.

Outside of the motivation, Aaron also spoke to Object, Rules, and Score.  Do you know the object of the game? What about the rules?  How do we keep score?  Our teams need to know how we’re going to operate, and why we’re doing this thing.  Constraints and boundaries are there to help us stay safe and keep moving fast, provided there are not so many that they get in our way.  And metrics and measures need to be known so we can tell how we’re doing.

Finally, we get into Religious Freedom.  Aaron stated that the methodology wars are over.  Nobody cares anymore. Lean, Kanban, Scrum, whatever process you like doesn’t matter, as long as we’re all working towards delivering more value.  We need to break away from the dogma and work on making the environment better.  Think about what makes sense, don’t just blindly follow somebody else’s rule-book.

Aaron also spent a good deal of time going over the process that Microsoft is now using, which seems to be some sort of mix of Kanban, Scrum, and Waterfall (Water-Kan-Scrum-Ban-Fall?)  I won’t go into details here, but when the video gets posted for this session I’ll link out so you can see that portion.  It’s a good example of how you need to look at your people, what you’re trying to do, and find what works best.  It’s definitely not what is ‘popular’ out there now.

Developer Populism

Dave West and Mik Kersten came in to put on a show about Tasktop and how it can bring our tools together, and while they were at it they framed what is happening out there in our crazy software world.  Essentially, software is eating the world.  The amount of software is growing faster than the workforce that builds it.  This means we have the power!

With the recognition in the industry that we need our teams to stay motivated (Dan Pink again!) and stay together, how this happens is now in our hands.  Our leaders want us to do well, and enjoy what we do.  To quote the title of one of the Birds of a Feather sessions, we need to be ‘Making Being Better Funner’.  Only the team knows how we can do that.  It means we have the voice in what tools we work with, and what processes we need to make ourselves do our jobs.

One problem with that: software makes money.  So as much as we want to use our tools and processes that help us do our jobs better, the money part means there needs to be more control, visibility, and management oversight.  This is where the session started in on ALM:  ALM is driven by management.  As Dave West put it, ALM is the marriage of business management to engineering tools to facilitate and integrate all aspects.  This leads to a war between management and development as to who has the control over this.  We know we need good tools, and management wants to easily see what is happening in all these tools to have a transparent exposure of the full lifecycle.  We need to have the one definition of the truth, but connecting these tools is difficult and costly.

So how do we get this one view?  Mik got up and showed us how to get the ‘TFS one vision’ even if folks don’t want to use TFS for all of their ALM systems.  Tasktop has some configuration mappings that let you tie work items together with artifacts in other systems and specify how fields map to each other.  So you can pull in your bugs in JIRA and keep them tied to bugs in TFS.  That way leadership gets what they want out of the TFS reporting and single-point of access, and the teams get to use the tools that they feel make them efficient.

Personally, I’d still rather keep one system than spend the effort pulling together a bunch of different systems, but I’m a bit of a control-freak so that probably means I’m dead wrong 🙂

In the end, there some messages for the different levels in the organization to take away:

• Practitioners: Take ownership of your tool kit, but choose an organizational viewpoint
• Managers: Embrace self-organization and autonomy, but connect to broader ALM vision
• Tool vendors: Embrace complex software ecosystems and heterogeneity, apply standards that allow interoperability

Agile Testing

I was pumped for this session because I’ve been spending a lot of time worried about making developers’ lives easier, especially when working with the folks defining requirements, but I haven’t had a lot of time to gain insight into how to get our testers to work better.

Previous sessions provided a little bit of coverage on the use of automation, especially on the developer side, and Brian Harry showed off the Web Test Case Management in Team Foundation Service, but Anutthara Bharadwaj was going to dig into what the common problems were, and how to really use Test Manager to do better.

The common challenges that agile teams are facing is that we need to generate the right documentation, even though we’re doing lightweight testing to support a short cycle.  Our testing needs to be rapid, reliable, and repeatable, which means the batch size needs to be smaller and the tests we run have to be faster.  How do we build in this continuous quality when the churn rate is so high and so many builds are being made?

Anutthara highlighted three areas we need to ensure with our agile teams:

1. Lightweight ubiquitous testing: Everybody has to be able to test, so we need to make sure tools are in place to support them.
2. Increased importance of test automation: Need to create a complex test configuration matrix despite shorter time and build tests that can automate across multiple systems and browsers.  And these tests need to run FAST!
3. Continuous Quality: We already know we need to test inside our iterations, but there are some tools we can leverage now to make this faster and better.  Automated tests that are part of the CI builds, using the whole team for quality, and using cloud technology like Skytap to support automated build-deploy-test scenarios,

The coded UI tests, in particular, looked pretty cool.  A single line of code to change which browser to target and we can record a UI test and then re-run it through multiple browsers.  Having the test cases in the web interface also lets us start running these on multiple devices and OS configurations without rewriting them or re-installing tools.

One member of my team has really been investigating Test Manager and using it on our project now, and I think we need to dig even deeper there.  It sounds like there are some things we can really do to improve how fast we can do regression testing with automation, even of things we would normally do manual tests with.  There’s going to be some be some fun with Test Manager when I get some down-time!

Agile 2.0

Israel Gat came in and delivered what reminded me of one of those university lectures that I would normally have to pay an exorbitant amount of tuition to hear.  The full title was “Agile 2.0: Software Development in the Era of the Open Graph”, which I must admit I did not understand… so I knew there was no way I could miss this session!  I cannot do any justice to the presentation by recapping it in text, so I’ll link out to the video when it comes out.  The entire pitch was basically around the fact that the upcoming economy is going to need us do go towards an API business model to bring the Firm and the Market together, and that means leveraging the community and making sure they can work with the products our industry puts out.

This means we need to move to a distributed backlog to take feedback in from the community and let them work on the things that the community wants.  Our demos will ultimately need to be replaced by continuous deployment followed by A/B testing to figure out what the community really wants to use.  If product developers want to be a part of the future, that is going to mean accepting to work like the Open Source community does.  Get people invested!

Closing Keynote – Re-imagining the Application Lifecycle

Sam Guckenheimer capped off our week with a great closing keynote on Build-Measure-Learn.  With a summary of the current state of the industry, Sam highlighted that the funding models have changed and enterprise budgets are shifting as well.  Enterprises have started leveraging open source components, and our development teams are becoming more and more distributed via outsourcing, specialized vendors and geographically distributed teams.  As we move forward, the budget is going to shift from the CIO office to the CMO office, focusing on market value of delivered projects.

In terms of ALM, Sam summarized our waves of ALM learning.  First, we addressed technical debt.  Our second wave was focused on amplifying the flow of values as understood by the customer.  The third wave is focusing on cycle time to allow you to learn more frequently and re-adjust.  This means our metrics need to shift to support learning.

1. Cycle time: From idea to deployment in customer’s hands
2. Mean Time to Repair: Issue identified to fix deployed to production
3. Experiments and Validated Learning: How quickly do we get feedback and input into the backlog?

Sam closed with a simple statement:  There’s no place like production 🙂