Delivering Software | LeanOrange

Hypothesis Driven Development(HDD)

February 8, 2013 — Leave a comment

We came across this picture while writing the Agile C’MON Man post. The irrational exuberance in this picture gave us a chuckle, but it also reminds us of an engineering group driving product development. As we articulated in the previous post, engineering driven product development can lead to BUFD. At the same time, we articulated the lack of business driven product development is due to ill equipped product management. In this post we will lay out a high level business approach to product development.

We think this is the new frontier for Agile and software development. The Lean Startup and David Joyce’s talk, 21st Century Portfolio Management, are great resources to start shaping how we need to think about driving product development. The fundamental principle that these two resources drive home is learning. Our ability to deliver higher value products hinges on our ability to learn. These resources also champion the fact that learning on the business side does not end after a business case has been delivered, nor after requirements captured, nor after a team has showcased working software at a demo. No, learning needs to happen with real customers. Therefore, we need to consider how we are going to learn throughout the whole lifecycle, including customer consumption.

Learning_Adoption Learning is not a new concept, especially when we talk about feedback loops in SDLC’s. However, the difference here is the measured approach to learning. We should not just ask what should be built, but why it should be built. Therefore, we should wrap measurements by which value returned can be measured and validated. It is this process of being intentional about quantifying results based on predetermined measures that helps accelerate learning. Documenting measures that align to our assumptions, force us to gain a deeper understanding of why our customers want what they want.

Experiments – You may have heard these forward leaning thinkers refer to this process as “running experiments.” At face value, this conjures up thoughts of lab rooms and scientists, but we’re doing software development…right? Well think about it. If we’re making assumptions and documenting what to measure after a capability has been delivered, it’s safe to say that this sounds like a hypothesis. If we build out that hypothesis and then measure the results, we essentially are running an experiment So it’s not that crazy after all.

Recently, a new “xDD” (x Driven Development) has hit the radar. Hypothesis Driven Development(HDD). Its so new, that there isn’t even a Wiki page for it! Mind blowing…I know! Whether you call it HDD, Lean Startup, 21st Centrury Portfolio Managment, or whatever, we think this is an area business product developers can gravitate towards to build better products. If you have thoughts to share on this topic, we’d love to learn with you! Please comment or DM us to continue the conversation.

In Business Driven, Continuous Delivery, Delivering Software, Lean Agile

Delivery as a Service (DaaS)

November 9, 2012 — Leave a comment

How many times has your team spent time futzing with build scripts and managing test environments or monitoring systems? This is a reality for development shops today. While this activity is absolutely essential to maintain stable assets, it does not scale well. As large organizations continue to demand more software solutions, we must think of different ways to manage, build, and deliver our assets. 20 different teams tinkering with Jenkins could get ugly fast. Not to mention the backlash effect of instituting a Jenkins change control board(JCCB)! 😉

What if scaled application developers didn’t have to worry with this headache? What if they just plugged their code and tests in and voilà…it works? 😀

Well, drum roll…ladies and gentlemen, I introduce to you Delivery as a Service(DaaS). DaaS represents the ops interface that developers interact with. This allows developers to remove themselves from the mundane tasks associated with building and maintaining a delivery architecture. Modern tooling, Lean Agile thinking, and mature engineering practices have made this possible.

DaaS is made possible by the thinking behind Continuous Delivery. Jez Humble and David Farley wrote a fantastic book in 2010, called Continuous Delivery, that outlined how to build more reliable systems by potentially delivering every application change to production fast, really fast. The success and maturation of Continuous Delivery systems is changing the mindset of traditional development. Companies such as Etsy, Netflix, and Flickr are pioneering the engineering practices required to build and deploy at scale.

With the help of these innovators and the work of the Scaled Agile community, we’re making sense of developing and delivering at scale. The Scaled Agile Framework calls out a program level team that would provide DaaS called the System Team. We think that a lot of innovation will occur at this level within SAFe over the next two years. If anyone has any experience with Continuous Delivery/Deployment at scale, we’d love to collaborate.

It’s an exciting time to be pushing code!

In Continuous Delivery, Delivering Software, Enterprise Agility, Scaled Agile

Enterprise Alignment

August 30, 2012 — Leave a comment

Alignment

In our consulting experience we have found many clients are excited to drink the Agile “kool-aid’ but for one reason or another fall short of a successful transition. There are many reasons failed transitions but one pattern that we have observed is a lack of “Enterprise Alignment.” So what do we mean by “Enterprise Alignment.”

An organization’s Enterprise Alignment is wrapped around three areas: technical architecture, business process, and culture. We have found that change initiatives fail when these three areas do not map to the overall goal of an Agile transformation.

For example, if an organization’s Agile transformation goal is to deliver business value fast, then all three Enterprise Alignment areas should align to that goal. Perhaps the technical delivery architecture take on continuous delivery characteristics, the business process would be focused on the flow of business priorities, and the culture would reflect a disciplined focus on shipping software.

Organizations fall short when they partially align themselves around these goals. They may have the technical architecture in place to enable fast delivery of software but are still operating on quarterly release schedules. Conversely the business process may be flowing the highest priority MMF’s or MVP’s to the development teams but the technical delivery approach is geared towards releasing batches of features through manual, late night deployments. Finally organizations may have the technical architecture and business process in place to flow features to production but lack the cultural discipline and collective ownership needed to consistently ship high quality software to production.

When considering an Agile transformation ask yourself, does my organization have the executive tolerance, courage, and leadership necessary to align the technical architecture, business process, and culture around the Agile transformation goal?

In Continuous Delivery, Culture, Delivering Software, Enterprise Agility, Technical Agility Enterprise Agility, Enterprise Alignment, Scaled Agile

Don’t sub-prime your project

July 20, 2012 — Leave a comment

Recently, a client ran into a roadblock…a major roadblock! For several months I had petitioned and warned leadership that investing the right talent to deliver results was putting the project at risk. However, no action was taken.

Essentially leadership took out a one year ARM hoping that they could deliver before the interest rate reset…i.e. team members to be repurposed towards other portfolio priorities. However, with the lack of the right talent the project made little progress. Month after month, the talent deficit accumulated into real project debt – software architecture, engineering disciplines, and team morale suffered tremendously.

Now management and the business are expecting the payment to come due(delivery). However they sub-primed the the project. With the expected due date coming up we’ll either need to refinance the project(add more time and/or resources) or foreclose.

So what? Irregardless of your process(Agile or not), when bootstrapping your projects, set your projects up for success. Put a solid down payment down to invest in realizing the project vision. Also, throughout the project lifecycle, actively engage the business and IT management…i.e. the decision makers. Transparency and active participation from stakeholders are key to Agile project success. Use this case study as an example where consistently disengaged decision makers caused project failure because they were unwilling to have the courage to make tough choices when the clear path to success was staring them in the face.

Reminds me of this sad Agile PM video: goo.gl/jYSWB

In Culture, Delivering Software