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

Stephanie Davis:

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.

Originally posted on 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 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

Stephanie Davis:

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”

Originally posted on 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 271 more words


Agile Manifesto 12 Principles: An Art Wall

I’ve been meaning to post this for quite some time now but life keeps getting in the way.  We (Valpak) moved into our new office space back in December, but I figure this is as good a time as any since we are a Coolest Office Spaces Finalist with the Tampa Bay Business Journal.   At our new location, each department like Marketing, IT, Business Development, etc has a custom art wall installation designed by our very own Creative Services team.  The art wall in IT is a tribute to the 12 principles of the Agile Manifesto and measures the longest of all the art walls at a whopping 80 feet wide.  At that size, trying to capture this art wall in a single photograph is impossible.  That said, here is a digital image so that you might appreciate its awesomeness.  Having the 12 principles so massive and visible helps us to keep the Agile Manifesto top-of-mind in all the we do.

Agile_IT Wall

 


The Top 10 Impediments You Avoid at OnAgile

Some of you may recall that this is my first year serving on the board of the Agile Alliance and … OH MY … have I been busy.   In my typical go-big-or-go-home style, I’ve taken on chairing our first ever virtual conference, OnAgile, alongside the almighty Declan Whelan. This year’s theme is “Navigating the Future: Emerging Technical Trends and Practices”.

I like to think of OnAgile as the world’s most convenient Agile event … and you can’t put a price on convenience, right?. In fact, there are many an impediment to avoid by attending a virtual conference and OnAgile is no different. With that in mind, I have for you “The Top 10 Impediments You Avoid at OnAgile”.

  1. Experience an amazing speaker line-up without having to get up from your cushy ergonomic chair or even leave your plush 10,000 thread count bed (if you choose to stay in bed, beware laptop burn which would create a whole other impediment). It’s like having the likes of Martin Fowler, Gene Kim, and Liz Keogh over for lunch, except you get to control their volume and even mute them on occasion.
  2. No need to miss your morning stand-up … unless of course you really wanted an excuse to.
  3. No need to beg your boss to fly you across the country to attend a live conference.   In fact, you are doing him a favor … better yet, you are doing the company a favor. And, at the cost of a couple extra-large pizzas, you could always choose to foot the bill yourself and avoid talking to your boss altogether.
  4. No pat down from the TSA because you forgot to leave your Snoopy toe nail clippers at home.
  5. Clothing optional! That’s right! So you missed laundry day because you were in flow for 12 hours on your latest side project. No clothes, no problem! Go commando for all we care. However, if you will be experiencing OnAgile from your office, we strongly encourage the use of clothing.
  6. No waiting in line to ask a question behind that guy that brought along his 10,000 lines of “dirty” code for Uncle Bob Martin to “clean” up.
  7. So your all-too-diligent ScrumMaster has you already booked to groom the backlog on May 14th. Don’t fret! You don’t have to experience OnAgile live to experience OnAgile. All of the speakers’ presentations and content remain available to you to access over and over again for up to 90 days.
  8. With a front row seat to OnAgile, there’s no chance of getting caught next to that guy that came straight from an all-nighter at the conference party.
  9. No more racing to get to a conference room to see Jez Humble before it fills up. Trying to convince the volunteer that you are fine to stand the whole time never quite works out. At OnAgile, everyone gets in to see the speakers.
  10. With a super-modern virtual conference platform displayed on your monitor, you will look plenty busy when your boss stops by to give you a new assignment or your spouse asks you to take out the garbage.

If you are interested in avoiding all of these impediments and then some, be sure to register for OnAgile 2015 at http://agilealliance.org/programs/onagile-virtual-conference/. The event will be live on May 14th and then available in a recorded format for 90 days thereafter.


MVP: The Zen of Software Development

Guest blogger, Toby Morris, is back with his take on the importance of Minimally Viable Product (MVP) in Agile.  Toby, known around these parts as “The Amazing Toby”, is a software developer at Valpak.  Enjoy!

When it comes to agile learning, development and growth, one concept rises to a level of importance few, if any other, concepts rise. With this one concept, if you grasp it, you will grasp the very heart of agile. If you can’t, you will struggle to reach the level of efficiency you should be able to reach.  Minimum Viable Product (MVP) is the soul, wit and zest of agile.

To me, agile is about maximizing the value and speed of delivery of the products my customers need and want. It’s about cutting waste and inefficiencies out of the development process. MVP is the deliverable with the absolute least number of features that will satisfy your customer’s needs. Period. Anything more or less isn’t good enough. Not enough features and the product may not be useable. Too many features and you’ve wasted resources and delayed getting the product to the people who need it most.

Minimum Viable Product is a concept that wraps up many agile principles, and it’s a tool for slicing through extraneous features. When looking at any user story, a first thought should be “how much of this is needed for a working product?”. Use the MVP blade to cut away at fluff and “wants” to get to the heart of the product. Try defining the product in a catalog blurb. If a feature isn’t in that blurb, then it’s probably not needed. Every feature that isn’t a core feature of a product is a wasted time in not only development, but also support.

Use the MVP blade to cut those extraneous features out of the current user story and add them to the backlog. If they are valuable, they will make it back into the sprint plan and into the product. If they never make it into a sprint plan, then they weren’t valuable. You just saved yourself, your company and your customer the time and resources that feature would have cost.

We’ve had customers at our company that ask for every possible feature during the early stages of a product’s development. They share a belief that if they don’t get everything in the first round, we’ll put features they want on the backlog, only to never find the time to get back to them. And that’s true. And that’s how it should be. If a feature belongs in the product, MVP will force you to include it. If it doesn’t belong in the product, MVP will relegate it to the backlog, where it will die a slow, cold death.

The Minimum Viable Product concept applies to anything you create. Anything you do. It’s the Zen of software development, and every other creative process. Whether you’re applying it to an entire application, a single feature of an application, or even a component of a feature, if you let it guide you, you will be surprised at how efficient you become.


OnAgile is On The Way

OnAgile 2015 Banner

Some of you may be wondering what I’ve been up to lately.  Besides my day job, I’ve been busy, busy, busy.  As part of my responsibility to the Agile Alliance board, I’m working with Declan Whelan to put on their first ever virtual conference — cleverly named “OnAgile” — on May 14th.  The theme for 2015 is “Navigating the Future: Emerging Technical Trends and Practices”.  Check out the Save The Date blog post on the Agile Alliance web site for more details.

I’ve planned a wedding (well, two weddings to be honest), I’ve planned an Agile Open (Agile Open Florida, that is), and now I get to plan a virtual conference.  And yes, we are being agile about it, employing not one, but two Kanbans from the start.  Super exciting!  I’m sure this is just the first of several blog posts on my experience in putting on OnAgile.


Follow

Get every new post delivered to your Inbox.

Join 1,020 other followers