Continuous Delivery: Fast Innovate and you will be Leaders’ Strategic Partner

Most companies understand the importance of innovation, but are not able to deliver software quickly enough to meet the needs of business leaders.  

Continuous delivery is the solution to improving the productivity of software development to the point of exceeding expectations and in turn creating the capabilities within technology departments so that they can play a critical role in the strategic direction of their companies.

The maturity model is divided into 5 levels:
1: initial – Ad hoc deployments.
2: managed – Planned release: Release time box is well defined, but duration from idea inception to production release is greater than business need.
3: defined – Regular release candence: Release time box is well defined, but duration from idea inception to production release is greater than business need.
4: quantitatively managed – Release on demand: Software is always in a releasable state. Release time box is well defined and equal to, or less than, business need.
5: Optimizing – Continuous deployment capability enables business innovation/experimentation.

Companies that do not exceed level 4 will be hard pressed to deliver innovation at an acceptable pace. Most companies that operate at or below level 3 will never keep up with the demands of business leaders and the market.

Resource: Continuous Delivery Speeds Up Innovation

Posted in Agile, Continuous Delivery, Innovation | Leave a comment

Impact Mapping: Deliver the “Right” Software

Impact Mapping is a collaborative planning technique that helps organizations define good objectives.

Impact Mapping is a technique that requires a cross functional group of senior business and technical people to align their expectations and visualize their assumptions together and it uses a collaboration model.

Agile techniques (XP, Srum, … etc) are much more about “how” than “what”. They’re much more about helping teams find out good ways of delivering software, not actually deciding what to deliver.

Large part Scrum and XP and Kanban have solved the problem of getting stuff out and lots of teams now can deliver almost anything that their business people want but they spend an insane amount of time doing the wrong thing and the bottleneck has moved for a lot of the teams. The bottleneck to great software now is delivering what’s really important, delivering what’s good.

The team can actually ship anything out, Impact Mapping will provide a really good fit for kind of getting the business integrated into iterative delivery and providing a lot more value to the business and the whole organization by doing the right thing.

Impact Mapping Princilpes:

1- Everybody should really understand why something is being done.

2- Organizations should really focus much more on achieving impacts rather than delivering software and achieving impacts through changing the way people work.

3- Decide what to do next based on immediate and direct feedback. Feedback that needs to inform what to do next, needs to come from the real use of the work, production use, not deploying to production, not acceptance tests, not somebody’s opinion but really the use of this thing.

4- Everybody cares. If you communicate why, if you focus on objectives then people will care.

Resource: Gojko Adzic on integrating business iterative delivery using Impact Mapping

Posted in Agile, Impact Mapping | Leave a comment

Software Project Estimation is Wrong – Part 2

Chrysler’s C3 payroll, the first Extreme Programming project:

“How will I know whether you’re on track or not?”
- You will be able to tell whether things were going well enough by looking at the stack of work that was done, and the stack remaining to do.

The project was ultimately cancelled. It took us some time to realize that there was a big lesson hiding inside that history.
The C3 project’s purpose was to replace the entire family of Chrysler payroll programs. It didn’t accomplish that. We should have replaced the broken bits, one at a time, most valuable first. The fundamental idea of making a complete list of everything payroll, and clicking through it, was wrong.

We supposed that the job was to build a grand new payroll program to rule them all. Wrong.

What we should have done, and could have done, was to solve the problems one after another, in the order that Marie and the other payroll people wanted them solved, and deployed those solutions as soon as they were ready.

Resource: Estimation is Evil

Posted in Agile, Estimation, Lessons Learned | Leave a comment

Software Project Estimation is Wrong – Part 1

Why estimation is wrong and will hurt you ?

1- Starting with All Our Requirements Is Wrong:
At the very beginning, we know less about our project than we’ll ever know again.

2- Estimating When We’ll Be Done Is Wrong; Forcing the Answer Is Worse:
Developers too, know less about this product than they ever will again, and they don’t understand most of these requirements very well.

3- Agile Teams Work in Short Iterations; They Pick an Amount of Work that They Forecast They Can Accomplish:
If a team has more work thrust upon it than they think they can accomplish, they generally fall short.

4- Having Demanded the Impossible, Management Asks for Better Estimates:

Posted in Agile, Estimation, Lessons Learned | Leave a comment

The Death of Knowledge Worker and the Rise of the Knowledge Networker

Why Knowledge workers era of supremacy is over ?
1- Speed of change today: An individual or self-contained group of individuals may know all the vital facts of their field in this very instant, but the speed of change can make their knowledge obsolete in the next instant – or even add volumes of new knowledge to the mix. No single group or individual can know it all and stay on top of it all.

2- No organization can hire all the knowledge workers it needs to cover every emerging need.

So, we now have a new era emerging: The era of the knowledgeable networker.

Knowledgeable networkers are very good at what they do, and at the same time, do not pretend to know it all. They consider the entire puzzle, not just their own area of expertise. They’re integrative thinkers with broad interests and connections. They see how puzzle pieces fit together without needing to know everything about each piece – instead, they KNOW A LOT OF PEOPLE and HAVE A LOT OF INFORMATION SOURCES. They have instant access to multiple knowledge workers via a phone call, email, Twitter post, or LinkedIn. They can bring experts and expertise into a team, a department, or organization to fulfill a specific need or help seize an opportunity. The knowledgeable networker can also seek out, find, assimilate, and translate useful information into workable solutions.

A group got connected on the Internet and crowd-sourced the design of a car. Project managers brought teams of experts together to build something amazing. They went from conceptual design to working prototype in a year. Even the best car companies take ten years to accomplish the same tasks.

It’s critically important that we cultivate a culture that rewards this practice of ‘bringing the outside in.’ Some organizations fully staffed with knowledge workers will fail because those employees are not networked internally to share the developing knowledge of their own organization.

Resource: It’s the End of an Era – Enter the Knowledgeable Networker

Posted in 2013, EndOfEra, Experience, Productivity, Programmers, Skills, Super | Leave a comment

My End of the World Post

Reblogged from Making the Complex Simple:

Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post

With the coming and passing of the predicated date of the Mayan apocalypse, I got to thinking about what kind of final advice I would leave the development world in the event of my untimely departure.

I suppose this is quite a strange thing to ponder given the circumstances, since if the world did indeed end there wouldn't really be anyone to pass this advice onto anyway.  

Read more… 1,709 more words

Posted in Uncategorized | Leave a comment

How To Improve Systematically In Your Job

Why you don’t improve? Because you waste too much time in shallow work.

Shallow work characteristics:
1- Easy, anyone can do it.
2- Attractive, because it is easy.
3- Rich in personal interaction, which we enjoy.

Shallow work examples:
1- E-mail replies.
2- Logistical planning.
3- Tinkering with social media.

Shallow work leads to job dissatisfaction.

Deep work leads to real satisfaction and remarkable career.

Deep Work characteristics:
1- Cognitively demanding activities.
2- Leverage our training.
3- Generate rare and valuable results.
4- Push our abilities to continually improve.

Deep Work benefits:
1-Continuous improvement of the value of your work output.
2- An increase in the total quantity of valuable output you produce.
3- Deeper satisfaction (aka., “passion”) for your work.

How to integrate deep work into your specific job ?

1- Prepare:
Go around deep work and prepare the scene for the action by stopping every other shallow work first then bring all the requirements for deep work.

2- Goal:
Set a big goal for weeks – a valuable goal and why it is valuable, then a small goals for every session. At the end of this one or two hours deep work, I expect this result.

3- Improve:
You have to struggle but not blocked while doing deep work. Google, read a book, think deeply, do sketching, ask an expert, google again. Find a task that is not easy and not very difficult, so that you extract the most out of your current ability and then improve.

4- Stats:
Calculate how much time you spend per day in deep work sessions.

Resource: Knowledge Workers are Bad at Working (and Here’s What to Do About It…)

Posted in Productivity, Skills, Success | Tagged , | Leave a comment

When IT Isn’t Strategic, Companies Fail

What happens when CEOs don’t understand the power and competitive value of information technology? In some cases, their companies go out of business or become marginalized.

People Express, one of the first low-cost airlines, PE’s founder and CEO had not understood the power of IT, so he had under invested in IT. American Airlines, with its advanced pricing systems, matched the PE fare, taking enough customers from PE that its flights became unprofitable.

By 2003 DHL entered the U.S. But DHL didn’t invest nearly enough in its computing systems. Consequently, it couldn’t manage its airline and truck operations effectively, price its services correctly, and, critically, provide customers with accurate information about their shipments. DHL got crushed.
DHL’s on-time delivery reliability was 10% to 15% lower than FedEx’s and UPS’s. When customers called to ask about a late delivery, DHL’s tracking systems were so inadequate that it often had no choice but to ship a replacement. It’s not surprising that customers returned to FedEx and UPS despite their higher prices. (By January 2009, DHL exited the U.S. domestic pickup and delivery market. In six years it had lost about $10 billion.)
Tracking and customer service systems should have been DHL’s highest priority, and the CIO should have pushed hard to get enough investment.

Kodak, which invented the digital camera in 1975, is being destroyed by the digital camera. How could this happen? Perhaps one factor is its lack of an impactful IT organization. As the digital camera era was just beginning, Kodak outsourced its one group that understood digital technology.

GROW not just MAINTAIN

Senior IT leaders at all companies must educate and press their senior management teams on the critical need to develop and commit to an IT strategy that grows the business, not just maintain a cost-efficient IT operation.

The visionary CEO to day-to-day CIO: “Saving money is great. But remember, that is not why we hired you.” He was making the point that I needed to stay focused on strategic applications of IT.

Having a very efficient IT organization is a good way to ruin a company. Why ? Because Senior business executives should know that a decision not to invest in IT is itself a strategic business decision. IT is transforming more industries than ever before, and businesses that fail to make those necessary investments and transformations risk everything.

Apple and Amazon’s inventiveness lay not in their technology but in how they exploited it to create uniqueness in the marketplace.

If IT isn’t part of the company growth agenda, part of improving customer experience, and part of developing innovative new products or services, it’s worse than a cost center; it’s a strategic liability. And it’s not a liability you can just close down or outsource to someone else and consider the job done. The decision to make IT a more efficient cost center is a decision to cede innovation to competitors, many of them newcomers, that can build their IT into a strategic asset.

Resource: When IT Isn’t Strategic, Bad Things Happen

Posted in Amazon, Apple, Companies, Creativity, Innovation, Management, Startups, Success | Leave a comment

The Myth of the Super Programmer

Reblogged from Making the Complex Simple:

Click to visit the original post
  • Click to visit the original post

I received an email this past week that disturbed me.

Basically the author of the email inferred that most of the topics I talk about in my blog posts and Pluralsight videos are relatively easy topics, but that I had hypocritically suggested that interviews should be hard and should be designed for “real programmers” or super programmers.

Essentially the point of the email was that application developers are not “real programmers” and “real programmers” do hard stuff with difficult math.

Read more… 884 more words

Posted in Uncategorized | Leave a comment

The Why is More Important Than the What

Reblogged from Making the Complex Simple:

Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post

The goal of software development is to solve problems.

At its heart, software development is really about solving problems through automation.

Many times we have the tendency to make software development about creating solutions.  It may seem that these are the same thing, but there is a subtle difference.

The difference is the focus

When we are trying to solve problems, we are obsessed with the question of…

Read more… 1,439 more words

Posted in Uncategorized | Leave a comment