Archive for the ‘Lean’ Category

Three 20 year-olds create a healthcare.gov miracle

Tuesday, November 12th, 2013

Up until the lurching non-roll out of Healthcare.gov, no one outside of the software community had ever heard of “Agile Development.”

The Wall Street JournalThe New Yorker, and Bloomberg have changed that.

Well, that and the miracle in San Francisco.

You see three 20 year-olds, in only 3 days, built a usable front-end to Healthcare.gov.

Miracle?

Yes, 3 people, in 3 days did what 55 independent contracting companies couldn’t do in 3 years with over 500 million lines of code.

There’s a miracle in there somewhere.

If nothing else, if you could get that kind of productivity out of your programmers, you would call it a miracle too.

Over the next couple of days and weeks, there’s going to be a lot of made of these 3, but how many smart business owners are stopping to ask, “How can I get that kind of productivity from my teams?”

In the coming days and weeks, I’ll be exploring that smart question.

Please pass this on to the smart business owners in your life.

How fast is your business’s cycle time?

Monday, March 18th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

How fast is your business’s cycle time?

 

Here’s a quick diagnostic tool for your company:

From the time funding is authorized on a new product, how many days does it take to get your first dollar of revenue?

This number is your cycle time. It’s similar to how fast a car can get from zero to sixty.

 

Before starting, there are going to be people reading this slice thinking, “Cycle time doesn’t apply to me because [really good reason here]”

Please, if this is you, before you leave this page, ask yourself, “How could this apply to me and my team?  What value could we get from this concept?”

 

 

[Those of you who are still with us, thanks for staying.]

 

If you don’t know your cycle time, you’re not alone.

If you do know your cycle time, you are far in front of your competition.

In most companies cycle time is in the hundreds of days. In a sad number, it’s over a thousand days. In a tragic number of cases, cycle time is infinite.

 

An infinite cycle time translates to: “The project was funded, staffed, started, and then canceled before ever making a dollar.”

 

What if I told you that there are companies that have a cycle time of zero?

What does that mean?

Tomorrow we’ll talk about how companies can have a cycle time of zero … or less.

 

 

In the mean time, start asking yourself:

What is my company’s current cycle time?

What is my department’s current cycle time?

What is my team’s current cycle time?

 

If you don’t know, guess, if you do know, ask yourself if there is any way to shorten your cycle time.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation.  If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community.  If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Scrum and the DOD

Monday, June 18th, 2012

I worked with the Air Force a few years back as a Scrum Master for a series of R&D projects.
In our office watching the movie “The Pentagon Wars” was required viewing.

Working with the DOD is problematic because you are not working with the customer, you are working with the contract office.
The contract officers usually have no visibility into the writing of the contracts.
On top of that, they are judged on how well the contract is followed, not on how well the resulting software meets the needs of the war-fighter.

The problem (or trick) is two fold.

1) you have to get your hands on the Colonel or General who is interested in the success of their project and is willing to have you make the software the way they need it, not like they specified it.
2) you have to write the contract in vague enough language that you could *almost* be playing half-life and still fulfill on the contract.

To a certain extent, we were highly successful.
We usually had Captains, Majors, and senior non-coms on our 2 week sprint reviews, occasionally we would have Lt. Colonels and Colonels in those meetings.
On our development team we had a former Air Force major (from the contract office) as our product owner, and another member of our team was a former naval flight Captain (O-6) from a carrier group.
Having these two on our team made a vast difference in being able to communicate that we understood their pain and were working hard to solve that pain.

Our biggest frustration was that the contract office only wanted our documentation.  They expected us to send them our source code as part of the documentation package, but that was incidental.
Yes, source code.  They never compiled the the software, let alone tested it.
Keeping the CDRL (“See-Druls”) up to date was just part of each stories done-done criteria.
The squadrons that we worked with loved how responsive we were to their requests.  They were amazed that we could put their requests into working code in a 2 week period.

Moving forward:

If you are working with the DOD, need to have a high level staff officer (preferably general grade) who will act as a sponsor and a go between with the contracting office.
This needs to be done *before* the contract is signed.
If you are working with an existing contract, you’re out of luck.

If you can get to a general grade officer and explain to him that you can put software that does what he needs it to do, and more importantly, that you can respond to his situation and give him what he needs today, not what he specified in the contract 8 months ago, you will go far.

The battle field military is a very agile organization.  They understand that they won’t really understand the situation on the ground until they get on the ground.
At the same time, military procurements have always (all the way back to the Romans) been full of graft, corruption and incompetence.
Our current procurement process is in place to try to minimize those excesses.

If you are writing software for the DOD, good luck.  It’s cool work, but its very frustrating at times.

Willem Larsen’s Language Hunting Presentation

Friday, January 20th, 2012

The language hunting talk was even better than it was billed.

Here’s the 64 minute recording.

 

If you are working on or around a corporate agile implementation, you will want to listen through the sound of lunch time at an Irish pub in downtown Portland Oregon on a Friday afternoon.

 

What you learn may not make total sense when you first listen to it, but if you ask anyone who was there, they will tell you that it was worth it.

 

Does your groups performance depend on your communication?

Tuesday, January 3rd, 2012

If you are in Portland this Friday, be sure to come down to Paddy’s Bar & Grill from noon till one to hear Willem Larsen discuss the subject of Language Hunting and accelerated team learning.

 

From http://calagator.org/events/1250461778

AgilePDX Downtown Pub Lunch
Friday, January 6, 2012 from noon–1pm
Paddy’s Bar & Grill, 65 Sw Yamhill St, Portland, OR 97204, US
Please proceed to the back room to find us.

Description: Effective group learning is synonymous with effective group communication and high performance. Language Hunting is a group learning methodology developed to save endangered languages through the tools of accelerated learning. Willem Larsen, President of Language Hunters, will lead participants in an experiential understanding of how accelerated team learning works.

Bio: Willem has worked in community education for the past 15 years—at the Oregon Zoo, OMSI, Tryon Creek State Park, and the Eddy Foundation Land Trust. He was a founding partner of Cascadia Wild! and a founding member of TrackersNW. Through his work in environmental education and local natural history, Willem came to realize that endangered indigenous languages are storehouses of priceless ecological knowledge, and this led to the development of Language Hunting.

Willem has presented Language Hunting at many Agile gatherings such as AgilePDX, Agile 2011 in Salt Lake, Agile Games 2011 in Boston, as well as being hosted at Agilistry Studios and the SolutionsIQ Agile Training Center.

Willem believes that languages, traditions, and skills are treasures that communities hold as a whole—only by learning together can we create the rich lives we want for each other.

Technical Debt – MIT says its expensive

Friday, November 18th, 2011

“… findings from the MIT Sloan School of Management, Agile businesses have a huge “Return on Agility”: 29% higher earnings per share; net margins at over 20%; the return on assets are greater than 30%; and revenue growth is a steady (always important to Wall Street) 8% or more.”

http://blog.castsoftware.com/the-financial-implications-of-technical-debt/

 

So technically, MIT says that Agility is good for business, but the rest of the article talks about how technical debt can take a smoothly running agile business and grind it to a halt with a very quick negative feedback loop.

 

If you have business people who are pushing for “more functionality now, you can fix it later” this article could save your sanity.

Software Developers and Capitalism – The $10,000,000 question

Wednesday, November 16th, 2011

Software developers seem to have a genetic defect when it comes to understanding the relationship between the work they do and the pay they receive.  This is not a good thing, and it is not going to change.  The reasons seem to come down to hubris and an unconscious attitude of “We don’t want to change and you can’t make us.”

My friend Nick Malik  once wrote about the subject in programming, contracting and pay.  There is room for an entire genre of books in this subject, but sadly, no market.  Approximately 99.99% of developers do not buy books about business or money, and therefore it’s not worth writing about it.

This is too bad because software developers often end up looking for work while blind to their true value to a business.  Software developers seem to understand that “my work is worth $x.xx an hour” but they do not understand the WHY behind it.  Their job worth intelligence score is very low.

 

You on the other hand are someone who is somehow interested in how businesses make money, and you are also not satisfied with minor linear pay raises.  In order to get 20 – 50 percent pay increases a year, you have to raise your job worth intelligence.

Here’s a quick little story problem to test your job worth intelligence.

Let’s imagine that company JKL has a particular job function (FooBar) that has to be done.  That job function will have to be done for at least the next 6 years.  The FooBar job function is so important that there’s even a FooBar department with 100 dedicated people performing the FooBar job function.  Every one in that department makes $50K annually.

JKL has access to a consulting group which offers a tiger team of 5 expensive programmers, each of whom cost $200K annually.  This tiger team has a track record of completing their projects on time and on budget.

The tiger team says that they can, in 1 year, automate the FooBar department such that the department can effectively cut %50 percent of it’s staff, immediately, at the end of the project.

The tiger team has one additional contractual item.  On successful completion of the project; each of the 5 tiger team members will be paid an additional $100,000 per year for the next 5 years.

Questions

  1. Is this a good deal?
  2. If you are the CEO of JKL, why would you hire or not hire the tiger team?
  3. How long would you have to think about it?
  4. By how many dollars will JKL’s bottom line be moved by doing this project?

 

Originally published by Malcolm Anderson on 13 July 2007 at
http://groups.yahoo.com/group/scrumdevelopment/message/24271
minor edits have been made for clarification

One Secret To Writing Understandable Unit Tests

Wednesday, November 2nd, 2011

Here’s a quick secret to writing understandable unit tests.

 

Name your object under test, the lower case letter o.

 

As in object.

 

As in

Foo o = new Foo();

 

The value of this approach is that in any test file, it’s very easy to determine what a particular test is trying to accomplish.

“What test class am I in?  The file name is Foo_Test.  In this case, o must be Foo”

 

It also reinforces the idea of one test class per application class.

 

Either way, when you come back to look at your code, you’ll be surprised at how easy it is to figure out what your intent was.