Monthly Archives: June 2015

Beginning an Agile Transformation at Your Organization: Shu-Ha-Ri?

Yes! Just like in The Karate Kid … “Wax on. Wax off. Wax on. Wax off.” Also, this is discussed in great detail in Chapter 4 of Lyssa Adkins book “Coaching Agile Teams” which I highly recommend.

agilefellow

I just attended the Agile Open Florida event in St. Petersburg Florida this past Friday and the attendees’ organizations there seemed to be split into three camps:

  • Some teams within an organization practicing Agile and the other teams practicing Waterfall.
  • Organization just announced or beginning transformation to Agile (2-6 months into it).
  • Organizations been practicing Agile for a year or more (at different levels of maturity).

My perception was that the majority of the attendees’ organizations fell into Group 2 and I would like to expose them and others interested to the teachings of Shu-Ha-Ri and the question of its adoption.

Shu-Ha-Ri is a Japanese martial art concept where the term translates roughly to “first learn, then detach and finally transcend”.  The definition pulled from Wikipedia follows:

It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These…

View original post 548 more words


The Base Model Theory

In follow up to his post in April on Minimally Viable Product (MVP), our special guest blogger, Toby Morris, is back with “The Base Model Theory”.  Oh, and a big congratulations to The Amazing Toby for his recent promotion to Software Developer II at Valpak.

There seems to be some confusion as to what constitutes a Minimum Viable Product. The MVP is the least amount of features that meet your customer’s needs for the product under development. That doesn’t mean it’s the least possible work you can get away with. It doesn’t mean you are allowed to skimp on quality. An MVP should have every bit as high quality as any product you’d put your name on. Those bare minimum features are still produced with your normal level of quality and craftsmanship.

Here’s a different way of looking at it.

When you go to buy a car, what would you expect if you bought the lowest price car? What would the Minimum Viable Product be? Would it be an engine on a wood frame, with maybe, if you’re lucky, four wheels? Would it have an engine? Of course it would have an engine. It would have everything you’d expect to find in a modern car. A steering wheel, seats, a radio and air conditioning would all be included. Leather, heated seats and satellite radio probably wouldn’t be included. Those are luxury features. Those would be found on upgraded models. Not on the base model. And that’s what a Minimum Viable Product is. A base model.

What goes into a base model? Well, that depends on your audience. You wouldn’t find leather seats in a base model Ford. The audience doesn’t expect it. A BMW probably should have leather seats. And heated mirrors. The BMW audience would consider those features necessary, not luxuries, or “nice-to-haves”. Knowing your audience is invaluable in knowing what your MVP would be.

Here’s a software example. Let’s say you want to build a notepad app. You want it to be the best notepad app, eventually, but right now, being agile, you want to build the minimum viable notepad app you can build. You don’t want to waste time adding features that your future users won’t use. That increases the amount of time you must spend developing the app before you can ship. And delaying shipping for unneeded features costs you money. Both in the time and resources spent developing this waste, and the loss of revenue from missed sales.

So let’s decide the minimum feature set. You’d need a functioning app that launches, shows your user a place to enter data, and a way to enter data. That’s the bare minimum to consider this a notepad. But is that the base model? Can you save files? Or load existing files for editing? If not, this isn’t a base model. You’ve not only left out non-essential features, you’ve also left out features your audience would consider essential.

To reach the base model standard, you add basic file operations. Once you get that running, you think to yourself that it might be nice if the users of your app could click a button and have the text they’ve entered be set to music automatically. Sure, that would be awesome, but it’s not a base model feature. That’s most definitely an option.

The next time you’re designing a product, and trying to cut out unneeded features without taking away too much, think about the base model. Would the feature in question be in the base model? Would your audience expect it?


Preparing for Agile Open Florida 2015 – No One Size Fits All

Mark does a fine job in preparing you for Agile Open Florida on June 26th. This year’s theme is so relevant right now in our community: “No One Size Fits All”

A servant leader's lessons

cropped-aoflogo-wideLater this month, I have the privilege of facilitating the Agile Open Florida 2015 conference.  Final preparations are well under way and we have sold out six weeks before the conference.  There is some personal preparation that would benefit everyone as well.  I’ll use the rest of this blog post to explain.

This year’s theme for Agile Open Florida is: No One Size Fits All

Who should come? And why? Anyone who has wrestled with the challenges of taking a team, a department, or an entire organization on an agile journey should attend.  This challenge is bigger than you.  You feel it is critical for you, your business, and your customers to “get this right”.  And there are so many things to get right.  So many questions to be answered.

But there is a catch.  There are many approaches to agile.  For teams, there are many choices such as Scrum

View original post 271 more words