Agile 2013 Recap

So the Agile 2013 conference is in the books and we could not have asked for a better experience for my home town of Nash Vegas. I heard multiple comments from newcomers as well as the veterans that this was one of the best and I have to wholeheartedly agree. Here's a quick recap from my personal experience:

The Sessions

Estimating Business Value (Chris Sims)

This was a very fun session with some good, hands-on exercises. I came away with some validation of techniques I have been using previously and some new ideas on how to train and coach on the subject moving forward. I had a forehead slapping moment as I realized his primary technique was almost exactly like what we do with sizing stories and I wondered why I have never translated that over to assigning business value. Chris is very engaging and made it a fun experience.

Agile Planning & Project Management (Mike Cohn)

The session I was headed to got cancelled and I popped into this presentation with a friend. I have seen Mike present on this material before and while there were a few new twists, it was basically the same information. While this was not new to me (I am a big Cohn fan already), it was a great session for anyone new the idea of User Stories, Story Points, Planning Poker, and Release Planning.

Enterprise Product Owner's Challenge: Managing Networks of Backlogs
(Alan Goerner)

While he never said it in the session, much of this content came from the much contested Scaled Agile Framework (SAFe). And while Ken Schwaber blasted it (and those who seek to sell it), I was validated in that some of the techniques for taming an enterprise backlog that he suggested were ones I have reached organically with multiple clients. I understand the mistrust of big frameworks promising the world as long as you use their software and services (I have been bit by that snake a time or two before..ahem..RUP), but I hate that it seems the good was thrown out along with the bad as the whole thing was often entirely dismissed. To say this was a sore subject among the attendees is an understatement. While chatting about it with some friends and Arlo Belshee (here let me pick up that name you dropped) at the Valtech conference party, a SAFe supporter stormed off from our table. 

Agile at scale at Spotify (Joakim Sundén, Anders Ivarsson) 

I had already read the excellent white paper on this, but it was nice to hear it direct from the source and there was plenty of "between the lines" content. They basically implemented a more Agile friendly twist on the matrix organization with a focus on the product and features. I've done variations of this in larger organizations, but this is definitely a go to example. Who wouldn't want to be on a squad as part of a tribe in their particular guild? I also love their office setup with each squad having its own development area along with a dedicated meeting space as well. This video by Anders has some of the same content.

LEGO TDD and Refactoring (Bryan Beecham)

Bryan Beecham's (with special guest Mike Bowler) session was the most fun. We were separated into tables with bags of LEGOS and he totally Miyagied us by having us make stuff with them and before you knew it, you were practicing TDD. It was an excellent exercise for non-developers (but there were several developers there as well and we all had a great time). I sat with Bryan and Tim Ottinger while they tweaked the exercise and it was very cool to see it evolve. Here is a link to Bryan's slides for the session.

Story Maps, Slices, Customer Journeys and Other Product Design Tools
(David Hussman) 

While this session was not what I originally thought, it was definitely interesting and informative. I have used mind mapping techniques for eliciting stories and to help slice them into small, workable components before. This was a new technique with a bit more structure that I am looking forward to trying out. This video is fairly close to the content David covered. He used a product called CardBoardIt that was an online version of how he did story mapping that might be something for distributed teams to try.

The Open Jams

Sometimes the best stuff you get is not from the presentations, but from the ad-hoc sessions called Open Jams. In the middle of the conference area was a big space with tables, chairs, flip charts, and white boards where groups could get together and talk about anything that tickled their fancy. If it strays from what interests you, get up and go to another one! I popped in a few of these.

This open jam was all about how to get teams and companies to be more collaborative. The guys from Spotify, Arlo Belshee, and Diana Larsen were there just to name a few. It was a very interesting discussion that I wished I had videoed. Each time we talked about some goal, impediment, or action around collaboration we kept coming back to trust.

As I mentioned before I sat with Bryan Beecham and Tim Ottinger while they were tweaking the TDD LEGO game and Tim kept rattling off study after study that applied to the various topics we covered. He has a wealth of knowledge that I wish I had had more to talk through with him. One that stuck with me was SCARF which is about how people interact with each other. Guess what it all started to boil down to? Trust. (Hmmm, I sense a theme.)

I walked into another group midway through their discussion about the language of learning. Diana Larsen was holding court and it was very enlightening how she mapped some of the higher concepts to concrete Agile practices. I asked her if the content was online somewhere and while he particular topics were not, she pointed me here. 

Socializing

Another great part of the conference is getting to unwind and hang out with everyone. There were some great events ranging from a simple dinner with a few new friends to an epic party on the Shelby Street Bridge hosted by LeanKit.

Online Content From Agile 2013

Big Visible interviewed a ton of the speakers and other thought leaders at the conference and you can find those videos and podcasts here.

Most the pictures in this post came from Steven List and are posted here.

Develop What's Valuable First

If you were developing a new application where would you start? Would you first create all the supporting frameworks for security, logging, etc.? Would you create the login screen?

Most of the time when  I've worked with new Scrum teams, they initially order the Product Backlogs sequentially along with the flow of the application: Frameworks, Login, User Administration, etc. This seems like a natural flow to creating components since it normally maps to the natural flow of the application itself to some extent.

But one of the basic principles of a Product Backlog is to prioritize by value. What do we mean by value? That could be many things such as ROI, risk, regulatory compliance, etc.

So, is the logging framework a highly valuable backlog item? What's the ROI? Little to none unless your company's primary business is selling logging frameworks. What about risk? Do we mean that it is risky to NOT implement a logging framework? No, when we push items to the top based on risk it is because we are not sure of the technology we are using or the approach we are taking so we want to implement the item sooner so that we can prove the technology or concept early on in case we have to change. So is a logging framework risky? Hopefully not. If you are a developer, with any kind of experience, you have implemented logging countless times and probably know a few out of the box frameworks you can easily integrate. So, it looks like we are simply building the logging framework first because it is our idea of a natural flow of building software applications.

But if we build all of the support frameworks, and the login page, and user management, etc. first, then when do we get to the real functionality that we are actually selling to our customers? Probably late in the game and uncomfortably close to our deliver date. Which means if we have any issues with these features we have less time to react to them and more likelihood we will have to work nights and weekends to "get er done" and probably have some quality issues once we do deliver.

So then what should we build first?

Ask yourself- 'what is the main feature set your customers are going to be paying for?' Build that first.

"What? You're crazy! I can't build that feature until I have all that other stuff you mentioned before."

First, I am not crazy, my mother had me tested.

Second, you can build those types of features first. You will have to unlearn a good bit of what you were taught as a tried and true architect in the layered application design. I am not saying you will not eventually build those things because obviously most of it is something you need to deliver a customer ready application.

I had a client in the financial services industry who was building a new product. Their initial user story sessions started exactly as I described above where the group started listing off the features they needed to build in the order of the application flow with several framework stories at the very top. I asked them what was the primary feature their customers were paying for in the application and they said transferring money from X to Y institution. I pointed out that this would be the best candidate for one of their first stories to tackle and after some convincing they caught on and ran with it.

Once we started breaking that down into smaller stories (since the original one was identified as an Epic) they once again start prioritizing the components of the feature sequentially: create a new X institution, list existing X institutions, create a new Y institution, etc. The story for the actual transfer of funds from X to Y was fairly far down the list. I once again asked what the most valuable part of this feature was to their customers and it was unanimous for the funds transfer.

Then the common questions rose up like: "How can we build the transfer from X to Y when we do not have the functionality to manage X and Y?" Do you sell X and Y management solutions to your customers? "No." You can create the simplest solution to populate X and Y even if it is just a database script. This way you can concentrate of getting the actual transfer part correct and demo that to your stakeholders and customer representatives first. That way you get feedback right off the bat and expose any implementation issues early. Then you can start to get to the other items such as the ability to add X and Y, login, logging, etc.

"You're crazy! How can we design the application architecture without knowing how we are going to implement security, logging, etc.?"

First, I am not crazy, the voices in my head said so.

Second, when building applications incrementally in an Agile environment your should follow the practice of emergent design where you build applications with just enough framework to support the current functionality but using an approach that allows for extension or replacement of these frameworks in the future. This approach includes the principles commonly called SOLID that help build decoupled, independent systems. Understand that there may be some level or rework, but just as we want to embrace change in the requirements in an Agile environment, you have to accept a certain amount of change in your architectural approach as well. We want to build features first and just enough framework to support them now and in the foreseeable future. Too many architects (me included) have gone all "mad scientist" when building glorious architectures that solve all the world's problems (even if they did not ask us to).

To further illustrate my point we talked to another team that had implemented Scrum on a previous project, but had built their features in that logical sequence. They were running on a 4 sprint release cycle and when they spent the first 3 sprints building frameworks and supporting functionality, they found that they had issues when trying to implement the core user functionality. By then it was too late because they were in their last sprint before their release. So what happened? They missed that release date and lost half the team in the next sprint to finishing the functionality. On top of that the rush to get it done left them with a ton of production bugs.

Now all of this is easy to say and harder to execute. Slicing up features this way takes practice since it often goes against your historical methods. While emergent design and SOLID principles sound great for building these types of systems, they do demand a certain level of development expertise and experience. But it is achievable and allows you concentrate on delivering your most valuable items first without weighing your application down with over bloated design from the start.

So when you start to prioritize your Product Backlog, remember to concentrate on value and not fall back on sequential flow.

I'll Be Speaking at Agile 2013

The Agile 2013 conference is being held in my backyard here in Nashville (not literally!) the second week of August. I will be speaking with a former colleague of mine, Fahed Sider, on "Agile Quality Assurance: The Long Ugly Tale of How We Got Better". This session goes over our shared experience at a company that was struggling with their adoption of Scrum and how we really turned things around in the Quality Assurance department.

If you are coming to the conference, I hope you can attend our session!

http://agile2013.sched.org/speaker/tommynorman

Nerds of Rock Event, Thursday June 13th at 7 PM

My company Holland Square is putting on a great event called Nerds of Rock. It will be held on Thursday June 13th starting at 7 PM. We'll have free food and free beer plus a house band laying down some tunes. If you sing or play an instrument you can jump on stage and jam with the band.

We are giving away some great prizes including an iPad Mini, Apple TV, Best Buy Gift Card, and more. Follow us on Twitter at @HollandSquare for updates and information on prizes.

Tweet about the event using the hast tag #NerdsOfRock2013 starting now for a chance to win one of the prizes at the event.

Register now at www.NerdsOfRock.com. See you there!

Nashville Agile User Group - April Meeting Recap - "Agile Certifications"

We had a great turnout for the Nashville Agile User Group's April luncheon and there was a good deal of information shared about Agile certifications.

I said I would post some links to online resources and here they are:

Agile Certifications

• Scrum Alliance is the most well known, providing a variety of certifications for Scrum Masters, Product Owners, developers, coach
• Scrum.org was created a few years ago by Ken Schwaber when he broke away from the Scrum Alliance in order to make a certifications program more aimed at practitioners and not merely trainers.
• Recently the PMI added their own Agile certification.
• The International Consortium for Agile has their own certification track (I don't know much about it) that was primarily started by Alastair Cockburn.

There were many interesting ideas bounced around and here is a basic synopsis:

Advice for an Individual Looking to get Certified

• Scrum Alliance's CSM is the most well known certification currently. The class content is not regulated so the materials may be different between classes. There are only a handful of courses offered in the Nashville area. Ask around about trainers from people who have already attended the course. Going with a big name in the industry is not necessarily the best choice. Most said the test was realtively easy based on the content from the courses. They did start offering a certification for developers, but no one had heard much about it.
• The PMI Agile certification requires a good deal of hands on experience. Both attendees who had pursued this certification were audited and had to get signed affidavits around their experience. Overall is a bit more costly than the CSM courses, but seems to have a bit more weight behind it. The material was said to concentrate on project management aspects but covered more than just Scrum. This book was highly suggested for exam prep.
• Scrum.org offers certifications that basically match all of the Scrum Alliance ones, but their course ware is the same every class so you know what to expect no matter whose class you attend. Some people had some very positive feedback about the developer course when was very hands on with .NET and TFS (they have a Java one too).
• Even if you are against certifications, many companies perform initial searches and screenings with them so you may be hurting your chances in some places.

Advice for Companies Looking to get Their People Certified

• If you can afford it, bring someone in house so that the training can be more focused on your company's specific issues.
• Remember that certification classes only go so far. Follow up hands on coaching was highly suggested.
• Look for training/certifications for everyone in your organization who will participate in your Agile process. Don't just get your Scrum Masters trained.
• Don't assume that certified training is better than those that aren't certified. Several people enlisted training without certification and were very happy with it. Look for deep, wide spread experience and references.
• Several people pointed out that a good many trainers target the project management side of Agile heavily and do not offer practical guidance on the practical engineering side.

Advice for Companies Hiring People with Certifications

• Certifications only show that the person holding them attended a class and passed a test. While some may be harder to get than others, certifications do not guarantee expertise.
• Look for people who have experience in multiple environments. Many people claim to be experts with a few years in one environment.
• Don't just look for certifications. You can miss out on some good people.

If you attended and think of something we covered that I missed, please let me know. See you next month!

Collaborative Sprint Planning

Recently while coaching a client's Scrum team, I noticed that during Sprint Planning the team was starting to concentrate on filling in tasks for their User Stories in the their Agile management tool Team Foundation Server (TFS) and less on the hows and whys around its implementation. This of course immediately drew me back to the basics of Agile from the manifesto of "Individuals and Interactions over Process and Tools". When I thought I had been helping the team by showing them a quick and easy way to enter tasks into TFS with Excel, that had turned around and become the focus of the meeting. This diversion had also started to manifest itself in the work being done in the Sprint as there was more friction between team members when what was being delivered did not exactly fit together initially.

It became clear that we needed to get away from the tool and get the team interacting more when discussing the User Stories so that they all walked away on the same page on how they were going to implement it. The next Sprint Planning only used TFS to bring up the User Stories initially. Once the story was reviewed, we had two members from the team (one developer and one QA) go to the white board where we wrote "Design" on one side and "Test" on the other. The team then discussed how they would test the story and how they would design the implementation to meet those tests concurrently. They drew UI mock ups, work flows, wrote out test scenarios, business rules, etc. Once they were done the tasks for the story organically fell out of what was on the white board. One team member would act as scribe and record all the tasks into Excel to be uploaded to TFS afterwards.

After trying this approach the next few Sprint Plannings (as well as in Product Backlog Grooming), the team agreed that they were coming away with a better idea of how to implement the stories and there was less friction between team members. Another benefit was that more test scenarios seemed to be identified using this technique and thereby increased our test coverage. This also helped make these meetings less tedious since team members were up walking around, drawing, and actively engaging one another.

So if you feel your Sprint Planning and Backlog Grooming sessions are straying from their true meaning, this is a fun approach to try and get them back on track.

Work In Progress Limit Poster

Recently a team I am working with was stressing limiting their work in progress during their Sprints so we made this poster to put up in their team area. I am sure it violates all sorts of copyright laws, but it would actually be cool to get a cease and desist letter from Devo. Enjoy!

Community TFS Report Extensions Version 1 Released

Last year Steve St. Jean and myself did some extensive work creating custom reports for a joint client of ours. The client was a large company well into an enterprise adoption of Scrum and other Agile practices. The reports we made them ranged from a set that helped make the testing efforts and work in progress in each Sprint more visible to multiple views of their Release Plan and its allocation of work to support software capitalization.

The client was gracious enough to give its permission for us to remove any of their proprietary material and release them to the public. Thus the Community TFS Report Extensions project on Codeplex was born.

We are happy to announce our first release of the report pack that includes our first two reports:

Test Plan Status Report 

The Test Plan Status is a report that extends the functionality found in the Test tab of Microsoft Test Manager.  While Test Manager can show you the completion status of the selected Test Suite, it does not show roll-up information when you have a hierarchy of suites.  This report is intended to fill that gap.

Release Plan Report

The Release Plan report shows the Product Backlog sorted by priority and overlaid with which sprint the items are forecasted to be delivered based on a given velocity. Only backlog items that have an effort, priority, and are in a valid state are included. Optionally you can specify a deadline which will appear before the Sprint it would fall during so you can see what items are forecasted to be completed by that date.

This initial release supports TFS 2010 and the MSF Agile 5.0 and MS Scrum 1.0 process templates (the Test Plan Status Report also support the CMMI template). We will be adding more reports in the near future along with updates to the current release with support for 2012 and some extensions.

Please take a look at the project and give us your feedback so we can continue to make these reports better. If you are interested in contributing, please let us know. The more the merrier!

Distributed Planning Poker and TFS

Mountain Goat software makes a great online planning poker application at PlanningPoker.com (funny enough). After registering for free you can create games and invite your team members to participate and cast votes for User Stories.

We used this for our distributed estimation sessions but entering all the stories was bit laborious. There is a great option when you create the game to import stories in a comma delimited format. When you are using Team Foundation Server you can create a query to export selected fields for your User Stories and add them all at once while creating a new game.

Create a TFS query with the fields you want to show in the planning poker game like the one below.

Open the query in Excel.

Then save the spreadsheet as a CSV.

Then open the file in Notepad.

Copy the column header rows and the rows with the User Story data. When you create a new game on PlanningPoker.com there is a field where you can paste the rows to import them.

Then when you start the game you can add each story.

Then your team can estimate each story.

Now if only they had an option to have it automatically update TFS with the result. Enjoy!

Agile Game Night Recap

This post has been sitting in my drafts folder for a few months! Sorry to post it so late.

On October 23rd the Nashville Agile User Group held an Agile Game Night to help people learn the principles and values of Agile through fun and games. While some really bad traffic kept some attendees away, those who braved the grid lock had a great time. Here's a recap of the games:

The Domino Effect

Benny Baggott facilitated the Domino Game. In this game teams estimate how long it will take them to build a tower of Dominoes to a specific height. Once they start executing the facilitator starts to treat each team a little differently to see how outside influences affect their progress towards their goal. Each team had different outcomes and it was a very interesting conversation afterwards.

It was noted that once one team finished and Benny started urging other teams to finish as fast as the first team they felt more pressure and knocked their half built towers down more. We discussed another option for running the game would be to have the different teams in separate rooms where they cannot see each other and then when getting estimates say things like "Really? That's your estimate? The other team was doing it in half that time." The idea is to illustrate how these outside influences from management can have a significant detrimental affect on team performance.

The Penny Game

Tommy Norman ran the Penny Game which a few people has done before in their certified Scrum Master training. In this game you simulate work by having 4 people at a table flip 20 pennies and pass them around the table. You start with large batch sizes and then reduce the size from 20, 10, 5, and finally to 1. The time each person takes is timed by their "manager" and the "customer" times how long it takes for them to get their first deliverable while the "CEO" times the whole process start to finish. 

After repeating the process with the different batch sizes you get some interesting conclusions from the time data. Time to market and total duration of a project is greatly reduced with the smaller batch sizes, but the individual performance is longer. The cost of each batch transition (passing the pennies to the next person) which could equate to any hand off overhead in your process adds up and reduces the efficiency of each worker but the performance of the whole process is much better. It is also a great way to also debunk the myths of productivity by making the individual parts of a process more efficient rather than the whole process.

The Agile Ball Game

This is another game some people had experienced as part of previous Agile training, but not as much as the penny game. Peter Balcarce led this game in which everyone is on a team who's goal is to pass around balls of various sizes to each other seeing how many they can get all the way through in 2 minutes. The rules are you have to have air time when passing the ball, everyone has to touch the ball at least once, you cannot pass to the people directly left or right of you, any dropped ball has to start over, and the first person who touches the ball has to be the last person. You get 1 minute planning and retros between 5 of the 2 minute sprints.

Those who have done it before are asked not give away the better processes for passing around the balls and to let the team self organize to figure it out. Generally the first run is very hectic and the team does not meet their goal. They normally regroup during the 1 minute retro and improve their process. On the second or third run the facilitator will start to remove people to simulate team members being called away for other important work. They also will bring in new team members who may not know the rules. The effect is that removing or adding team members almost always causes a significant disturbance.

Some other observations we had were that when we were tossing around balls of roughly the same size (like tennis balls) we established a good rhythm  but when balls of drastically varying sizes were introduced we were not as efficient. This is a great game for managers to show them how shuffling teams has a detrimental effect on their performance.

GetKanban Board Game

Chris Hefley and the gang from LeanKit Kanban introduced the GetKanban Board Game which is a fun, hands on way to learn the basics of Kanban. There are several versions of the game, some you can download for free, and everyone who played had a great time and said it really brought home the concepts of WIP, bottlenecks, lead time, etc.

Thanks
We'd like to thank all attendees and those who helped facilitate the games. We would also like to thank our sponsors: Holland Square Group, Vaco, LeanKit Kanban, and Omnicell.