Wednesday, January 08, 2014

Speaking at Memphis Agile User Group Jan. 30th "Agile Quality Assurance: The Long Ugly Tale of How We Got Better"

I will be speaking at the Memphis Agile User Group on Thursday, January 30th. This is the same presentation I did at the Agile 2013 conference last year called "Agile Quality Assurance: The Long Ugly Tale of How We Got Better" which got a great response. You can register here.


The session covers my experience at a past employer helping them adopt Scrum over the course of 2+ years and all of our trials and tribulations during that transition. I played many roles over that span including developer, QA manager, Scrum Master, and Agile coach and the presentation covers man of those aspects but has a strong focus on QA.

I lived in Memphis for about 5 years in the 90s and always love to go back. Anyone who is up for a trip down to Beale afterwards should let me know.

See you there!

My Scrum Fundamentals Video Goes Live This Week

I recently had the pleasure of working with the crew from Pearson Publishing and created an online training video called "Scrum Fundamentals". If you are a Safari Books Online subscriber you can already access it here, and it is available for purchase on InformIt.com here.



While I have been training, coaching and speaking on Scrum for years now, it was a totally new experience filming a video of this type. My producer Irene Magafan from RHED Pixel was a huge help it getting me through the three day shoot and the rest of the team did a great job filming and editing the final result.

This video has over 3 hours of content from my "Agile Software Development with Scrum" training class we deliver at Holland Square Group and covers the following topics:

  • History of Agile and its values and principles
  • Basics of Scrum including roles, artifacts, and events
  • Starting a Scrum Project
  • Managing your Product Backlog
  • Writing good User Stories
  • Agile Estimation and Planning
  • Prioritizing work
  • Working as a Scrum Team
  • Planning for a Sprint
  • Executing and tracking work in a Sprint
  • Agile engineering principles and practices
  • Integrating QA into Scrum
  • Dealing with bugs
  • Delivering a product increment
  • Inspecting and Adapting your process
I am very happy with how it came out and I think it gives a solid overview of implementing Scrum. It's a great option for educating team members new to Scrum where sending them to instructor led training is not an option. You may also want to incorporate it into your onboarding process and is something you can use with off-shore teams as well.

Tuesday, August 13, 2013

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.




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.

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.




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.

Monday, July 08, 2013

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.

Tuesday, June 11, 2013

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