July 24, 2014

All Posts Tagged With: Enterprise Agile

Agile Coaching Blog

Postcard From the Field: “It’s beautiful. Wish You Were Here to Share Our Agile Success!”

Over the course of the last couple of months, I’ve been working with a client who is interested in changing their approach on how to handle what they term as “Big Rocks” in IT for planning, execution, and delivery.  We had our first demo and retrospective yesterday, and I felt a tear of joy in my eye.  So, I thought I’d share a little progress report from the field with you on some agile success.

We started with a business requirements document that took about 2 people years to develop.  Some of the items in this long document were items that haunted the organization for up to 4 years.  The normal next steps would be to take the requirements and submit them to the various silos of development for specifications, come up with project plans, manage the dependencies between the development silos, engage QA, and hopefully integrate everything together at the end and release the new and improved system.

My coaching and mentoring strategy was centered around the normal set of Agile and Lean values, principles, and practices that I employ to get organizations thinking in an Agile mindset.  I did add a new visualization to the mix, the “Agile Fluency” concepts that started with James Shore and Diana Larsen, which are being popularized by Martin Fowler.

Agile Fluency

We would start with the business leaders and decision makers on making a shift into business value focus at the organizational level for teams to be newly formed and sustained, with each team able to deliver independently on the software side of the value proposition considered.

Strategic Planning 

From the start, I made it clear that whatever new process we came up with, I wouldn’t just try to make for better planning of dependencies between the software layers and better tracking of actuals versus estimates.  To start, I wanted the organization to take a fresh look at what made sense to do from an economic perspective, and then use Lean principles of waste elimination to guide us on how to execute the plan.  Core to all thinking was the concept of a feedback loop, so we could constantly exploit variability as the landscape changed.

The results were both surprising and expected.  After looking at appropriate lightweight monetization of benefits and cost, the first and most beneficial epic emerged – which was to be expected.  However, what was surprising was how the business started to see that a point of diminishing returns would be reached only 6 months or so into the backlog created from the initial business requirements document that would easily be expected to take at least 18 months to complete.  This started raising eyebrows and opened people’s eyes about how to better spend those development dollars for other items on the organization’s portfolio of work to consider.  Rolling budgetary planning would occur monthly (which I think is a bit too rapid, but we needed to try and learn from it).  The organization decided to stop forming teams around projects, limit their WIP for projects under development, and bring the work to the teams as part of their Scrum product backlogs.  There were some vocal skeptics about how this could never work, but the client’s senior leadership team gave the go-ahead for a limited trial of the new way of approaching work.  For me, I couldn’t have been happier! 

Rolling Agile Planning

Tactical Execution

As we started up the first team to execute on the newly value focussed single stack ranked backlog of work, we faced a really tough decision.  The organization was used to silo development with project-planned dependencies resolving the (infrequent) points of integration with a UAT blessing at the end saying that the right stuff was built, followed by a QA stamp of approval that everything in the applications all still work.  The application architecture was rather complicated, with web, middleware, and backend layers of components.  The deployment process is manual, hard to coordinate, and fraught with peril.

My suggestion for Scrum team formation was to bring all the development layers together with the Product Owner into one project room and begin to develop the skills to consistently deliver on the value.  Additionally, I really wanted some of the Agile Engineering practices of Continuous Integration, Automated Regression Testing for both white and black box testing, and Automated Deployments to be started and gain some traction. I felt that without reducing the entire concept to cash cycle time, these new organizational cultural shifts would be tossed aside quickly as hard and expensive, and a reversion to the status quo would quickly occur once I left.  We got support from all the development silos with the exception of QA, who pledged to add a person to the team, but would not commit to enabling them to develop automated tests as we developed the code.

Our initial iteration planning went as well as could be expected for a team that was unaccustomed to working with one another in such a close and collaborative fashion.  Our Definition of Done for stories included using Ant build scripts that invoke JUnit, SoapUI, and Selenium webdriver/PageObject tests run on a Continuous Integration server (which was to be built in this first iteration).  It was a pretty tall technical order with huge uncertainties for a team that needed to get comfortable with a new way of how *they* approached work. 

I was honored to see this team get its work done.  Was it perfect?   Nope.  We had to do some backlog grooming a few days into the iteration, because we hadn’t had a chance to get completely through the backlog, and wanted some idea about what the general shape of the release would look like.  To our horror, when we started digging into the workflows and UIs that support them, we saw that a story that we had completely worked through make it impossible to implement something that we now were trying to wrap our arms around.  Right after we discovered this, the Product Owner had to go to the full Delivery Team and say, “Gang, I know that this is what I said we needed during our iteration planning.  But don’t do that.  I just figured out that I need something else!”  Conversations were had, and the team felt comfortable once again.  At the end of the iteration, during the demo, the Product Owner recounted the story, and then explained to everyone, “if we had done this in our previous process, we could have had to wait 3 months to even see that we had a problem!”

9625106215_fb87c73292_b

Image Source

The demo was also super cool when the developer that put together the CI server wanted to show what the tool looked like and what it did.  Just that day, the developer was asked about a small change that needed to be researched from an architectural perspective for the next iteration.  Going out on a limb, the developer made a code change in that direction during his demo, and committed his work.  The CI server kicked in, and allowed him to show the product owner what that new feature might look like.  In real time! Before, that level of system integration would have taken days to deploy, just to show what something would look like. In the past, decisions would be made based on documentation, but that’s not as valuable as seeing the actual new feature running!

Anyway, it was one of those all too rare victory moments for teams at this client.  Senior leadership team members were thanking the team and saying how they were amazed on the amount of progress that could be demonstrated in just two weeks.  We have a long journey ahead, but we’ve gotten started on the right foot.

Anyhow, I was so impressed with this team’s progress that I decided to send this card and share their success with you. It’s beautiful. Wish you were here!

7045709267_670c4dc7c0_b 

Image Source

 

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Effective Lean Portfolio Management – Stopping The Thrash To Make Some Cash

I was lucky enough to be involved with a mid-sized client recently who happened to be in the medical insurance analytics industry.  Lucky is maybe a weird way to say it.  The engagement was one of the hardest I’ve been involved with in recent memory.  But as I look back, the outcome was so satisfying that the success overshadows the pain we endured.

Things were fairly desperate when I got to this client.  I had a briefing from the CTO of the parent company on what was happening.  I was asked to help the PMO figure out how to do a better job with portfolio management and help Development staff get stuff done.  I made the following observations:
  • Development was extremely busy and no one was very happy.
  • The product that Development produced had a reputation for poor quality, and that didn’t make the business team big believers in the ability of Development to deliver on time, on feature, or on budget.
  • There was never time to do the right things because there were constant emergencies that development had to quickly react to in order to avoid disaster.
  • The way that the company approached work was to get funding approved through the PMO (a lengthy process) and then form a team of developers that were already working on other items.  That is, new work that got approved (such as emergency work) simply given to already saturated resources.
  • The PMO worked against project proposals, and the primary factor to getting a project approved was to verify that funding could be secured.
  • Projects were tiny, down to the size of mere sub-features.  Just about ll decisions were preplanned in terms of features, approach, and people.  The planning of project-to-project dependencies was enormous, and when things changed, which they did frequently, things were replanted ad nauseum.  Progress, when it occurred at all, was in tiny increments, and took a really long time.
  • iStock_000031710336Medium

    So, this wasn’t a simple case of “Gee.  We have 7 people in development, and they say that they’d like to try Scrum to do their work.  Can you train us up and get them started?”  For BigVisible to be successful with our client we had to:
    • Only claim success if the client was successful.  Did that mean that all six of the problems observed were completely gone, the sky was bright blue filled with rainbows, and that unicorns dotted the landscape?  No, but we had to at least move the needles in the right direction on the problems.
    • That implied that solutions straight from the “Agile Playbook”, like a great plan to roll out Scrum and train everyone up wouldn’t fly.  BigVisible is known for creative non-obvious solutions, and however hard that would be, we’d have to be up for the task.
    • We also had to not be afraid of “the storm” with the client.  There was still political fallout at the company. Reduced product deliverables were resulting in reduced revenues which was resulting in reductions in the workforce.  This all made the atmosphere at the client quite toxic at times.
    In thinking this through, I decided that the focus of this portion of the engagement was not about the delivery and execution side of the equation at this level. I didn’t want to focus on team level metrics when looking at these strategic issues. I knew that eventually, we needed better Agile Engineering practices, such as automated regression testing, to get better quality.  But it was my feeling that pivoting the client to focus on value delivered (rather than cost of production) and looking at a smaller number of projects overall would be helpful.  From a lean perspective, way too many decisions were made too early on, and ended up having to be analyzed again and re-decided.  Those decisions were made in a document-centric fashion, and were expensive both in terms of time to create as well as time to distribute and educate.  The decisions were also made not just what needed to be done, but how to do it.  Those “how will we do it” decisions were made by non-delivery people who, although good-intentioned, were not necessarily in line with either the reality of how the systems actually worked.
    In a nutshell, I wanted the organization to:

     

    • Plan less projects and plan less deeply.  The projects should allow negotiation from a “backlog of work to be done” perspective.  The projects should not have all the design decisions and estimates pre-made, especially by those who do not actually code the work.
    • Include value in the decisions of which projects to go forward with.  Stop planning to only control cost, but start a pivot to plan for the best value, using cost as just one factor.
    • Limit the number of things that the organization works on at once, so that the organization could become effective.
    • Appropriately manage the portfolio of work “in process” and “to be done”.  Make economically rational decisions on the portfolio.  Plan based on a roadmap of value and review the progress periodically. And, much like the way a stock portfolio should be managed, don’t fall into the trap of the “sunk cost fallacy.”  Instead, I wanted more of a “bygones principle” to be used when making decisions.

    DCF 1.0
    At BigVisible, we feel that a transformation performed without goals and results is just an exercise for a customer to try out some potentially cool stuff and see if they like it.  We don’t believe that we are in the business of having a hip storefront that advertises how cool you’ll look wearing some new process.  We don’t believe that the way you measure the success of an engagement is to see how much behavior the client is doing that seems more “Agile”.  We believe that to be Agile, a client has to have better outcomes than when they started.  So, we set the following goals for measuring our success:

    • Do releases occur without heroics?  Or are they followed by countless emergency releases?
    • Do releases occur with the MVPs (minimum viable products) as part of the release?  Or do they consistently disappoint due to quality of features so poor as to render the release a toxic wasteland?
    • Does the finger pointing and tension between Product and Delivery subside and actually have them form a real team?  Or does constant acrimony between the two sides continue?

    iStock_000006681572Small

    The transformation didn’t always go smoothly.  We instituted our own Lean BMC (Business Model Canvas) and added items to help visualize cash flow over the effective life of the product, monetizing costs, benefits, and risks.  It was hard on the organization to think about work differently – we were asking them to not make tiny decisions about what, how, and who for each small feature or defect.  We were asking them to limit their work and attempt to create a single rank ordered list of potential work. We were trying not to “optimize” by matrixing the organization’s staff in a fashion that would destroy their effectiveness through constant meetings and task switching.

    Two people were thrilled with one aspect of the transition – the CEO and the CFO.  The use of NPV (Net Present Value) calculations to forecast cash flow and understand the capitalization implications on their business resonated with each of them.  While they really wanted precision in accounting, they understood that better accuracy due to not just looking at the costs, but also considering the benefits side at the same time gave them a powerful tool to understand what products should survive in the rolling management of the portfolio we put in place.

    Interestingly, when we started with planning the portfolio by single stack ranking the product proposals, we decided to get right at it.  We brought the heads of Product and Delivery together; sat them in the same room.  And they took the time to plan the business as part of a real leadership team.  There were very tense and tiring days, especially the first time through the process.  However, they both agreed at the end of the strategy sessions that they found deep appreciation for the issues and common ground to build upon.
    Now don’t get me wrong.  Things were not perfect.  There was a “pet project” that we knew would lose a relatively small amount of money.  And somehow, we could never cross that line and drive a stake through its heart, kill it, and keep it killed.  But at least people were able to articulate that, instead of using politically aspirational excuses for keeping the project going.
    So what did we learn, and how did the client’s work change?

     

    • We learned to focus on product value, and think in terms of longer timeline horizons.  We had to put hyperbole on a holiday, and actually make economic sense quarter by rolling quarter.
    • We learned to limit our work in progress (WIP), match demand to supply, and start thinking in terms of bringing work to established product delivery teams, and not just forming “teams” around scattered projects. Less thrashing around allowed us to focus and actually deliver quality product.  Teams were redirected into new product work, only on a quarterly schedule that allowed them time to focus and finish that which was started.
    • We learned to think about appropriate measures and metrics in terms of strategic planning.  We didn’t optimize the individual projects.  We optimized the organization.
    Oh, one more thing.  That client recently contacted me to ask about how to better integrate their process with corporate FASB and GAAP capitalization policies.  I was also informed that they are improving on their BMC on their own.  Nothing could make me happier.  Hopefully, they will continue to improve and set the bar even higher for Lean Portfolio Management!

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

The Capacity for Change – An Agile Case Study

Improving quality and speed-to-market, two of the most common challenges an organization can face. Now get 10 teams to meet that challenge and scale it further in order to better visualize the work flow across the business. Maybe even set up a few “enablement teams” to make sure that success is sustained. Here’s an agile case study on an organization I’d like to introduce you to. They’re the organization that did it…successfully!

Just the Facts
The Challenge: Train and launch agile teams for the product group of a broadband Internet pioneer with 400+ employees.

The Client’s Goals: Better follow-through on execution, faster speed to market, higher quality

The BigVisible Approach: Assess the current situation, design a plan, start sprinting. Adjust the plan, scale, and offer suggestions to sustain results.

What We Delivered: Results that met client goals, plus an organization-wide understanding of capacity versus demand.

Summary
Over a seven-month period, our agile coach worked with a broadband Internet provider to launch 10 agile teams with the goal of improving quality and speed to market. Using the SAFe framework, our agile coach helped the leadership team better visualize the flow of work across the organization. This big picture view enabled them to reduce log jams by pulling from a prioritized product portfolio. The client also implemented two agile enablement teams, who are working to sustain success by extending agility beyond the software teams.

WANT TO READ MORE? DOWNLOAD THE CASE STUDY NOW!

download

Share:

All About Agile: Giora Morein’s Interview with Money For Lunch

Earlier this month, I was interviewed by internet radio show, Money for Lunch. The program introduces leaders, authors and innovators to a business-minded audience focused on business and financial news. I spoke with Bert Martinez regarding the topic of agile. We went over some of the basics, such as:

  • What is agile and Scrum?
  • What are the common pitfalls of agile or anti-patterns an organization might see?
  • How does BigVisible avoid the pushback and get organizations to successfully adopt agile?

I speak to the topic of agile as a fundamental shift in how large organizations view the delivery of products and projects – going from big batch, long-phased delivery cycles to something iterative and incremental – quickly bringing products to market.

It’s easy for organizations to become bogged down in their own processes and systems. But more and more, organizations are widely adopting and scaling agile to be more responsive, to increase quality and achieve more successful outcomes because the market is demanding it. Buyers are more knowledgeable and know what they’re looking for and they demand better product in shorter timeframes. If organizations can’t deliver, they won’t be able to remain competitive.

You can listen to the full interview here.

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Curiosity as a Leading Indicator of Agile Adoption Success

As I reflect on how engagements go, I’ve come to ask myself, “Why do some teams and organizations take to agile adoption better than others?”  It’s a tough question.  But one that is important to me as an agile coach and how effective I am. Especially in the context of how to get better at it.  It’s important to BigVisible, because as an organization, we need to understand how to do agile coaching better than anyone else out there, and keep  improving.  And, of course, it’s important to our customers, as that’s what they are paying for!  There is both a personal and organizational reputation riding on providing the very best for them.

A few months ago, I found myself facilitating an engagement retrospective.  I asked coaches to fill in cards on thoughts of what went on and place them on a wall that was titled “Our mission here was to change the way that this client approached work.”  The  cards were ordered laterally with the extreme left being “Yes, we did!” and the right-hand side being “Opportunity for improvement.”  It looked something like this:

Retrospective Wll

As we worked through the items, one item on the right-hand side struck me right between the eyes:

 Increase curiosity card

And the reason for this pain in my forehead?  I’d been thinking about that item for a long time, but could not articulate the best way to relate it to engagements until that afternoon.  But ever since that fateful day, as I run my hypothesis against engagement after engagement, I’m seeing a correlation that can’t be denied.

It all started a few years ago, reading the Robert Lucky column in the July 2012 issue of IEEE Spectrum.  The title of that month’s Lucky opinion was “Curiosity.”  Lucky spins a tale of how he was explaining the way that GPS worked to a friend, only to have the friend avert his vision and explain how he didn’t care about those sorts of things, and that only engineers cared about that sort of thing.  That got Lucky curious about curiosity and thinking about whether engineers were any more curious than others.  In any case, Lucky mentioned the Monty Hall Paradox, which I have actually used myself to gauge how deeply people are willing to explore an idea to understand the texture of the problem before simply asking for a solution. 

image source

For those that aren’t familiar with the Monty Hall Paradox, allow me to explain.  Monty Hall was the host of a TV game show called “Let’s Make a Deal”, which aired from 1963 to 1977.  During the show, Monty would pick a couple and bring them to the front.  They would be shown prizes that were placed behind one of three doors that they could win by guessing the correct door.  Behind one door might be a brand new Cadillac.  Behind another door might be a week’s supply of breakfast cereal.  And behind the third door might be a goat.  The couple would choose a door, and Monty would show what was behind a different door (perhaps the cereal).  They would then be asked if they wanted to switch doors.  There would be a lot of discussion, squirming, sometimes screaming, and they would choose.  Eventually, the lucky couple would either go home with the new car or the goat.

In 1990, Marilyn vos Savant, a columnist for the Parade Sunday magazine (who happens to hold the Guinness Book of Records honor of having the world’s highest recorded IQ of 228), wrote about the Monty Hall Paradox and explained that if you were to switch doors when Monty showed you that one of the doors you didn’t pick didn’t hold the grand prize, your odds of winning that grand prize doubled.  That is, when you originally were asked to pick a door, you had a 1/3 chance of winning the grand prize, but when you switched after being shown that one of the doors did not hold the grand prize, your odds were now 2/3 of winning.  With such a seemingly illogical result occurring (why didn’t the odds stay at 1/3, meaning that switching made no difference), floods of letters were sent in.  Some by prominent mathematicians!  For more information on the paradox and the way to understand the reasoning behind it if you’re stuck.

Anyhow, Robert Lucky tried asking a dozen of his friends (engineers, I take it) about the Monty Hall Paradox and found that none believed that switching would increase your odds of winning, and none were curious about why.  I’ve done my own highly non-scientific study of the matter on people I’ve worked with on various agile transformations.  I even get emails from some of these folks from time to time, with comments like “I just read a mention of Monty Hall and thought of you.”  My results show a correlation of people who are curious about why the paradox gets the result that it reaches and the success of the transformation I’m working on.  And I have a hypothesis about why I see this correlation.

Agile transformations within an organization involve an evolution of the organization.  One that challenges the organization to always question itself and see where things can be improved.  Not just a simple-minded “Do Scrum!” or “Setup a Kanban board” and expect wonderful things to happen.  For a real transformation to occur, people have to start with where they are and question how things could be improved.  That means starting with “why”.  The solutions proposed are not sure-fire.  We have to make a change, inspect the results of the change, and then adapt to a new state.  The changes that need to be made require creativity, as the complex world of software development is a domain where small changes may have results that are quite non-linear.  Especially in large enterprise environments, which have their own complexity in politics, communication, and interactions.

I firmly believe that creativity requires a certain amount of joy in the workplace.  If things are dull already, and people are afraid to say or do anything that might “make waves”, then my assumption is that they are likely to just go with the herd and slog along making small talk along the way.  It’s the ones who aren’t afraid to shake things up – the ones that aren’t afraid of ridicule or worse – that make the best change agents.  I firmly believe that if I were to administer the Monty Hall Paradox “test” as part of an early assessment for a new client, I might be able to distinguish which organizations will have successful transformations and which ones will attempt to stay the course, with just minor improvements along the way, like having delivery teams do a 15 minute status call each morning and label it a Scrum.

I may just run this experiment to prove my hypothesis and publish my results someday.  But before I do, let me ask you.  Do you have any anecdotal evidence that curiosity, creativity, and the ability to have fun are related to success on an agile transformation? 

NY Times Interactive Feature for The Monty Hall Problem

Monty Hall interactive visualization from the New York Times 

 

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Mind the WIP to Become Effective, Not Merely Efficient

Mind the WIP to Become Effective, Not Merely Efficient

“Efficiency is doing things right, while effectiveness is doing the right things.”

We’d all like to be efficient.  We’d love to show our boss how cheaply we can get something done, compared to all her other options.  We’d like to have extra time, maybe to clean up, beautify, or just goof around.  Efficiency is the hallmark of mass manufacturing.  If we build it for less, we have more profit to put in our pocket.  But did you ever consider that when we build software in situations where resources and dates are fixed that you’re making a huge, risky bet?  I venture to say that you’d rather ship 80% of your product features on a certain date (and have least valuable 20% left over for “the next time around”) than be 90% done on everything and have absolutely nothing to ship on that due date.

You probably have 2 questions at this point.  “How could that be?” and “How can I be effective, and not merely efficient?”  The answer to both questions is found in three tiny letters – WIP (work in process).

It all begins with estimation

Let’s take an easy example for this piece.  Here’s a list of things that we’d like to develop some software for and release to our new website in the next 90 days:

  • Allow website users to search for and display lists of items in our warehouse
  • Give website users the ability to display pictures and details for an item that they select
  • Give website users the power to display real time inventory status for an item that they are looking at
  • Give website users the ability to create a “shopping cart” of quantities of items that they select
  • Allow website users to complete a transaction and pay with credit card(s), PayPal, direct checking account, or any combination thereof

Assume that since we only have 90 days, the Delivery Team that we have, is the army that we will use. The 90-day window is non-negotiable, because we paid a zillion dollars for a Super Bowl ad that will drive traffic to our website on that fateful day.

If you’re a traditional, plan-driven project manager sort of person, you probably do this project by first decomposing the software stack into components that we’ll put together, and then create a project plan that pulls people, time, and dependencies together and convinces us that everything will be fine.

  • Database for the warehouse items
  • Component to access database
  • Website functionality for search
  • Website functionality for display
  • Website functionality for real time inventory
  • Website functionality for adding, displaying, deleting, and modifying items in the shopping cart
  • Component for integrating our warehouse system with the website real time inventory status
  • Component for implementing the shopping cart on the server
  • Component for credit card processing
  • Component for PayPal processing
  • Component for checking account ACH processing
  • Component for payment coordination between the various processing options

OK.  Got the list.  Get some estimates from various people.  Assign developers against the tasks.  Adjust estimates to make everything fit inside that 90 day window (Tell me that you’ve never done this.  Be honest!).  Announce “It’s going to be tight, but the plan demonstrates that we can do this.  So, let’s get going!”

With software, the odds of everything working in your project plan are a lot like your odds of hitting the Trifecta

But here’s the rub.  Estimates are made for things that we haven’t previously done.  We use our best effort to understand and give meaningful honest estimates.  And we do.  But the uncomfortable truth is that effort-based estimation for software construction is highly variable, due to a variety of factors:

  • Uncertainties with how to do things that we’ve never previously done.  For example, we’ve never tried to interface with our mainframe based warehouse system before.  We may find little nooks and crannies of problems and issues which we must solve to permit the integration that we never considered when we gave our limited “happy path” estimate.
  • Uncertainties around what things we should actually build.  For example, should that real-time warehouse inventory level stop people from adding items into their cart? Stop them from completing a transaction? Or just ask them if they want to place the item on backorder?  We’ve never done this with customers before, and we can’t be sure that customers will bring us enough value to cover our costs of development, since we’ve never before given customers this ability.  If we have to re-do a lot of work for a fully fleshed out feature, that could cost a lot.
  • Uncertainties based on who actually does the work.  Your best developers may be 10 times (or more) productive than your least capable ones.

And then we completely hide that variability in estimates by expressing a single number for the estimate.  The estimate, even though it is expressed as a single number, is really a probability curve.  It might look something like this:

Graph Source

And, finally, we completely compound and confound the problem by linking the tasks together with scheduling dependencies.  “We can’t start/finish this task before finishing/starting that one” (either because of software functionality dependencies or resource dependencies). Our project is a hope, wish, and desire that everything goes according to plan, even though we mathematically know that things will go wrong, and will start to cascade through the chain of scheduling dependencies.  If we start creating the compounded probability of arrogated estimates, we start to see that the nice peak on our bell style estimate distribution curve starts becoming very short and wide.  And our chances of hitting our estimate square on are about as likely as picking the “win, place, and show” horses, in order, at the track.

Yet somehow, seeing everything fit together in a nice Gantt chart that magically ends right on target makes us feel safe and sound.  At least when we start.  But without fail, almost every project plan that I’ve been around goes sour quickly.  One late dependency quickly snowballs into an avalanche of late tasks that just compound and worsen. Blame starts getting metered out.  Morale goes through the floor, and when we’re living the day before the game, we try to integrate everything, and nothing is working.  And now that the business sees the real time inventory status in action (when it sort of works) they aren’t sure that they want it, as they now realize that when people see that an item won’t be in stock for a couple of weeks, they may decide to go elsewhere!  But we’re so afraid that pulling out the code will break 20 things against the middle.  So, it’s part of the deployment, like it or not.

Gantt Chart

Our attempt to be hyper-efficient and get each and every feature working the day before the end suddenly becomes an #EPICFAIL when things don’t work on Super Bowl Sunday.

That’s horrible!  What’s a Mother to do? 

What if we turned this on its head?  Let’s say we start with a single ranked ordered list something like this?

  1. As a website user, I want to search for items to purchase using words in an item’s description, so I can find things to buy.
  2. As a website user, I want to display an item’s description, price, and primary picture, so I can decide if I want to purchase it.
  3. As a website user, when I click the “Buy It Now!” button on an item’s display page, I want a quantity of one item placed in my shopping cart so I can purchase it when I’m done shopping.
  4. As a website user, when I click the “Proceed to Checkout” button, I want my shopping cart displayed with checkout options.
  5. As a website user, when I click the “Purchase Now!” button with the “Debit My Checking Account” option clicked, I want an ACH setup to my checking account for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: this transaction is free through our bank.  Yay!
  6. As a website user, when I click the “Purchase Now!” button with the “PayPal” option clicked, I want my PayPal account to be debited for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 1% merchant fee on PayPal transactions.
  7. As a website user, when I click the “Purchase Now!” button with the “Mastercard” option clicked, I want my Mastercard account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 2% merchant fee on Mastercard transactions.
  8. As a website user, when I click the “Purchase Now!” button with the “American Express” option clicked, I want my American Express account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 4% merchant fee on Mastercard transactions.
  9. As a website user, when I want to be able to change quantities and delete items in my shopping cart when I am checking out so I don’t get frustrated with a shopping cart that is not exactly what I want to purchase.
  10. As a website user, I want to display an item’s auxiliary pictures, to help push me to clip the “Buy It!” button.
  11. As a website user, I want to display an item’s real time inventory status, to help me decide if I want to buy the item now.  Note: the website user may decide to not buy the item when they see that it’s not in stock.
  12. As a website user, when I click the “Purchase Now!” button with the “Multiple Credit Card” options clicked, I want the ability to setup a complicated transaction [details to be thought through], so I can become a happy and loyal customer.  Note: we have to figure out technically what happens here, how to back out of scenario such as having one card going through and a subsequent card failing.
  13. As a website user, I want to backorder an item that real time inventory shows as out of stock so I can eventually purchase the item.  Making this happen will invoke a workflow involving eMails, order cancellation, and other things.

Notice what happens when we start to develop one thing at a time, in this order, and get feedback from the business as we complete each of these items.  If we got some of the details wrong (it happens all the time!), we can immediately get that right before we move on.  When the business says “Good!” on each item, we then get our deployment to stay “always ready to ship”.  If we run out of time, we may not have every feature completed, but we always have something to show on Super Bowl Sunday.  We’d like to get through the whole list, but we don’t even really know the details for some of this yet.  But we have enough to get started.

Untitled 2

What was different?

That’s easy.  We minded the WIP.

We made sure that we had the highest value items worked first, and did one thing at a time (“Single Stream Flow”, in Lean terms).  We were always ready to ship.  That allowed us to work right up to game time without fear that integration would ruin things.  We didn’t have to worry that we wouldn’t get to go home for the next two days, subsisting purely on Mountain Dew and day old pizza.  We concentrated on delivering value one step at a time, from most important to the least.

That pivot to focusing on business value, rather than figuring out the optimal plan that gets us to done can be a huge mindset change for some organizations.  Sometimes, managers are afraid that someone won’t have something to do when the team is working through the business value ordered backlog of functionality to create.  But remember, every time we add to our WIP, we create the potential that dependencies will keep us from being ready to ship.  We create the potential to very efficiently work on lots of stuff at once, but have nothing to show for it when the clock runs out. That’s not very smart.  And it’s awfully risky. It sure isn’t an effective way for your organization to work.

The prime directive is effectiveness – efficiency is only secondary

I don’t know how it works for your business, but for mine, I’d rather deliver 80% of the highest business valued items and leave the remaining 20% of lowest value items for sometime in the future.  I really don’t want to be 90% done with everything, but having nothing to show for it when the clock runs out, because that last 10% was needed to get anything to work.

For me, Meatloaf said it best, almost 40 years ago.  “I want you, oh, I need you.  But there ain’t no way I’m ever gonna love you. Now don’t be sad, oh, ’cause two out of three ain’t bad.”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

 

Share:

But It’s Just a Simple Matter of Coding – How Hard Could It Be?

Many times, I hear business people (such as Product Owners) bemoan how expensive software development is.  And the brutal truth is that for anything non-trivial, software costs a ton of money to develop.  I happened upon some numbers for a fairly simple but elegant iOS app called “Twitterrific”.  Twitterrific is a client to the Twitter network, uses a well defined interface created by Twitter, and does not require any backend development.  It runs on the iOS, which is a well defined, well documented, well supported, and stable environment for both development and use.  According to an article published on the PadGadget site, Twitterrific was developed by a single person (Craig Hockenberry) in about 1100 hours.  The article goes on to do the math at $150/hour, adds in design, testing, and so on, and comes up with a number of around $250K.  That’s just for labor.  No costs for a workplace, infrastructure, developer tools, and so on.  Once you start adding in enterprise costs for offices, management labor, etc., and start building multiple tier complex applications, It’s easy to see why business people would look at the finished work (knowing how they interact with computers, which has become easier and easier over the years) and wonder “How hard could it be?”

That burning issue perplexes many organizations.  It isn’t usually an issue with companies with disruptive products – when margins are huge, things become profitable quickly and easily.  It isn’t usually an issue with a young, well funded company – if there is a long enough runway covered in money, and you aren’t accountable for showing profits until sometime far down the road, costs are not the issue.  However, it is a huge issue in many enterprise IT settings, where capitalized expenditures are rigorously scrutinized to see what work can be done under the funding constraints that exist. So, why is software such an expensive thing to create?

Here are four reasons that I find compelling.

  1. For anything other than trivial software, the potential for failure due to complexity and development risks is huge.  Back when mainframes ruled the earth in the 60s and 70s, the average program was thousands of lines of code. Today, it is very common to see applications that are tens of millions of lines of code. And, since any line of code can potentially affect any other line of code through side effects, a program that is 10 million lines of code is one million times more complicated than a program that is 10 thousand lines of code (a so called “n squared” problem).  The care needed to create code that works at all, and the potential to have bugs emerge is astronomically high.  While we have better tools now than we had forty or fifty years ago, they aren’t a million times better.  Trust me!  I developed software on machines back then as well as now.
  2. Programming is more like an art than it is engineering.  Engineering and building large and useful things on schedule has become commonplace nowadays, and people count on it.  For example, Tommy Lennhamn (from IBM), states that “Examples of successful engineering projects, at least with respect to schedule, are all the construction projects for Olympic Games — as far as I know, all Olympic Games have started on time, on fundamentally new premises.”  The secret is that with engineering problems for things like constructing buildings, components to build from are well known, assemble together well, and don’t create too many unknown side effects when bolted together.  In that type of situation the hard part about the project is agreeing on what to build.  With software, many times the business doesn’t know what to build until they build something to see if it solves the problem.  But that operates in a doubly damning world where developers don’t have the components that assemble together without knowing for sure if their construction in one place has affected something else (and someone else) in the code base.  Not withstanding the efforts of TDD, we can never prove correctness in software to the same extent that we can with mechanical construction.
  3. Not all developers are created equal.  The barrier to enter the field is relatively low.  This attracts a lot of people to compete for relatively high paying jobs.  But, as people like Steve McConnell point out (in IEEE Software, Vol. 15, No. 2), “…differences of more than 20 to 1 in the time required by different developers to debug the same problem” exist.  Does it make more sense to hire one awesome person for $200K or 10 mediocre people for $90K each?  Remember, once you hire 10 people, communication issues will slow you down (Fred Brooks “Mythical Man Month” stuff, but I digress).  While there may be a glut of cheaper labor today relative to the salary requirements of the awesome developers (due to such factors as geographic outsourcing), the reality is most enterprise IT settings would never hire the really awesome developer at a relatively high pay grade, due to political issues. And, even if they could, they would be hard pressed to find talent willing to work in the stodgy environments that many enterprise IT settings have become.
  4. There is still a wall of disengagement between business and development that needs to be broken down.  The Agile movement of the last 13 years has done a lot to publicize the need to have “Product Owners” engage on at least a daily basis (with continuous engagement being the best), but it is still very common to see business people physically and geographically separated from development.  Worse yet is when enterprise business people complain about how much “more important” work they have to do, and how they yearn to return to the days of yesteryear, when they could ask the Project Manager for a status update, and then complain when things were behind schedule.  Lean thinking tells us that faster feedback loop cycles will create less waste, and therefore more and better product.  Given the realities of 1-3 above, and the cost associated with those items, I implore such business people to stay with the development teams and help them help you reach the enterprise’s goals.

It’s a shame that software is so exquisitely expensive to make, as the opportunities to enrich our lives by using relatively cheap hardware is everywhere.  Everything from smart thermostats (such as the “Nest”) to smart light (such as the Philips Hue) to truly personal computers (such as Samsung Galaxy Gear and Google Glass) surrounds us.  And it all takes programming computers in one way, shape, or form.  Unhappily, programming computers is anything but easy.  But if you consider that humans have been building houses, roads, and bridges for thousands of years, and are still faced with colossal failures from time to time, it sort of puts things into perspective.  Programming will continue to evolve into something more of an engineering practice someday, and programming may eventually become something relatively simple.  Of course, we’ll have to find something else to complain about if that ever occurs!

Kinky for Governor Poster

Kinky Friedman ran for governor of Texas in 2006 on the slogan is “How Hard Could It Be?” While this was a great line, no one, including Kinky himself, ever believed it. Even Kinky admitted that “I’ll hire good people!”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share: