Adopting Agile Development - The role of the CIO

I've been covering the CIO path to credibility. First, the CIO must be able to negotiate priorities and develop a path for consistent delivery - which is why I thing the CIO loves Agile (or should love it). So if you are buying into my methodology, the next step the CIO must determine is how to introduce an agile development life cycle to both the Technology and the Business organizations.

Now my assumption is that if you're reading this blog or post, you know a fair amount about agile development and planning. So I'm going to stay specific to the role of the CIO and responsibilities you must take on.

1) Sell it - The key question - how will the organization benefit from shifting to agile? Expect to get lots of questions. How will it affect business priorities? How will resources be trained? How long and expensive is this shift? The CIO has to anticipate these questions and work with his leadership team to plan the transition and be prepared to answer these types of questions.

2) Identify executive business sponsors - First, migrating to agile is a lot easier if you have a strong business executive sponsor. If you don't have that yet, you'll have a harder time selling and proving the benefits, but that shouldn't discourage you from taking on the challenge. Make sure that you keep executive sponsors (or possible ones) updated on the team's successes and how you're overcoming challenges. Invite them to demos even if they can't come. Here are some of my thoughts on getting Executives to buy into agile.

3) Identify the initial project(s) - I don't believe in shifting multi-team organizations to agile in one shot. Most agile coaches will tell you that the agile process needs to be adapted to the organizational dynamics and business needs. For that reason, it's best to select one, maybe two projects, get agile working, then look to scale a process to to other teams. What makes a good agile project? A good option is to find a business important project that has no/few requirements (early inception stage), will require several months of effort from one or only a few teams, and is most likely to benefit from an iterative delivery cycle.

4) Help the project sponsors - Shifting to agile can also be a major change for business sponsors. You have to sort out how to fill the product owner role (see: Agile Product Owners in the Enterprise). Sponsors have to learn how to work priorities, requirements and scope changes in this product life cycle and IT leadership have to help Sponsors learn their responsibilities. See my posts on Business Responsibilities working with Agile Teams Part 1 and Part 2.

5) Help the team make it successful - Make sure all team members have a basic foundation in an agile (probably scrum) process. I highly recommend training and ideally an agile coach if you can afford it, but at minimum make sure you have a team lead (scrum master...) who's been through a successful agile project. Make sure the team has a basic process in place even for iteration #1 and attend a few stand ups to help with the blocks and other issues that arise. Help individuals understand their role in the process and identify skill set gaps.


6) Find and manage the skeptics - Assume that you'll have skeptics with any process change and even the possibility of saboteurs. Look for the signs and help manage these situations.

7) Define self organization - This is a key tenet of agile, yet there are boundaries in organizations defined by policy and practice. Policy might define financial boundaries, rules on how technology is selected, change management practices, etc. Also, talented teams can easily extend self organizing principles and attempt to take on the responsibilities of other teams. 

8) Don't leave out QA - The QA team has to redefine itself quite a bit when Development teams move to agile. There are some folks in the agile community that believe the QA function is replaces by agile's short/iterative delivery cycle and with the maturity/adoption of unit testing frame works. I'm not one of these people. I'll have another post on this subject but to keep things simple for now, the CIO should get active to make sure that QA responsibilities and resources fit into the organization's agile process and methodology.

What did I leave out? I might need a part 2 to this post...

How the iPad could be a Game Changer

Doing some poking around today and this evening on the iPad, and the vibe I'm getting is ho-hum. Gadget enthusiasts are somewhat disappointed on the lack of some features (sd card, camera) but investors are enthused over the $499 entry price. Obviously the Apple designers had to make some tough calls on what hardware features they had to include given constraints on cost, physical size, and battery life.

But the overwhelming vibe I'm getting is that the iPad is just a larger version of the iPhone. Interesting, but not a game changer. Do I want to pay for and then carry the larger size iPad if I get all the same apps on my iPhone especially if I still need a laptop with keyboard to do my work? CruchGear's take; "It's a big iPod", "As a developer, I’m excited about it. As a consumer, not so much.", " “one more thing” to carry around. That I definitely DON’T need." CIO.com quotes Rebecca Wettemann, analyst at Nucleus Research. "What we've got is a color Kindle—a Kindle for dummies—at a higher price point."

What's missing?

In simple terms, the apps followed very closely by the real problems that it solves for consumers.

The apps were a big success point for the iPhone because it was the first smart phone to bring a large family of useful applications to consumers - so much so that 100K+ were created and consumers were willing to pay for them. The success of the iPad will not be the portability of these iPod applications. I doubt consumers will pay for a larger device just to run the same apps.  The iPad success will come from the next generation of applications specifically built to take advantage of the device's screen size and other features. This can happen for five primary reason:

• There already are a large number of developers familiar with the programming model.
• Consumers will likely be ready to pay for the portability
• Companies simply have to dial back their investment in their websites and increase their efforts applied to developing iPad apps - proportional to the number of users that purchase the iPad.
• Certain types of consumer applications will thrive with this type of device. Magazines will salivate on the rich display, the ability to embed ads, and the ability to charge for subscriptions. A new breed of games will be created. I could also see a renewed attempt to develop applications for the "home" - kitchen/recipes apps, home improvement apps, etc - all taking advantage of the iPad's size and portability. 
• Enterprises will consider deploying these devices for parts of their workforce and deliver better functionality, higher mobility, and simplicity - all at a lower cost than deploying a laptops. The sales force is an easy example who could have a better device for accessing CRM tools and making informal presentations. 

Will the device change user behaviors?


Let me answer that based on personal experience.


If you asked me my thoughts on the Kindle three months ago, I would have said, eh, why do I need it. I don't read a lot of books. But after getting one - and even after seeing that some of the software functionality is at a 1.0 maturity - I'm still excited over it and it has changed my media consumption behavior.

In the last year, I've purchased and read exactly zero paper books. Nothing driving me to find books, not interested in carrying them, and little time to read them. But that's changed with the Kindle for one very simple reason. It's now practical for me to buy several books, "carry them", and switch between them based on my immediate interests. Tomorrow morning I might read a chapter of the latest book on innovation, on the way home I might read a chapter from a foodie book, and this weekend a chapter (hopefully several!) from a novel.  I'm buying books again - all because the Kindle made my consumption model convenient, useful, and fun.

So will the iPad be transformational? We'll see.

Why the CIO Loves Agile Development

Let's say you're following my last two posts on negotiating business priorities. You're the CIO and have just been given a set of business priorities and now need to get your IT team aligned and executing. Let's play out a couple of scenarios:

• You go back to the sponsors, assign a business analyst and work on requirements and a project plan. Once requirements are largely stable, you then look at delivery options, technology choices, assign teams, etc. We all know this as the waterfall approach.
• Option b, the agile methodology - would essentially assign a team to work with the business manager to identify the most business critical, or technical risky aspects of the project. The team would then commit to some deliverables it would provide in a relatively short iteration - usually 2-4 weeks. The team would then offer to demo their work at the end of the iteration, then would focus on the next set of critical items for the project.
  

Obviously, I'm grossly simplifying but want to point out a couple of key differences. In waterfall, the project team has to engage the business manager for a significant amount of time and up front work to define requirements. Projects are broken into milestones that have no specified rhythm of delivery (some milestones may be weeks, others months) and no requirement or expectation to demo functionality. Bottom line, the CIO taxes the sponsors up for details and must wait an undefined period of time to demonstrate milestones of product delivery.

In agile, the CIO is getting the following significant advantages:

• Low up front business investment - Teams can start working on the most critical features and risky technical areas without overtaxing the business sponsors for up front information.
• Frequent delivery leads to better execution - Let's say your teams does two week iterations - in three months they complete six iterations giving them plenty of time to prove themselves, mature the agile process, and time for the CIO to make adjustments. This is really one of the key points since no team is perfect and tech execution always carries risk. CIOs can leverage this process to prove the team's credibility. 
• Allowing Sponsors to prioritize at the beginning of each iteration leads to better Business / IT alignment. The Sponsor gets to prioritize based on customer feedback, the CIO gets the IT team direct engagement from the Sponsor.

If you're the CIO trying to establish credibility and dialogue (beyond negotiation!) between Business and IT, agile planning, development and delivery are very well constructed management processes to enable both short and long term success. Also see that:

Credibility + Dialogue = Collaboration and that Collaboration between Business and IT Leads to Innovation.

Why CIOs Must Negotiate before Collaboration

Several CIOs questioned my last post and why The Most Important Job of the CIO is to Negotiate with the Business  and not collaboration or partnership?  So before I get into how CIOs can establish credibility, let me elaborate a bit on my last post. My rationale on negotiation before collaboration is quite simple:

• Before you can collaborate and have a true partnership between Business and Technology, the Technology Team has to have credibility and a strong record of delivery. Once the technology team is credible with a well understood delivery model, Business Managers have a lot more incentive to invest their time to consult with Technologists on their future plans. This consultation is the basis for collaboration and partnership.
  
• In order to get to credibility and a strong record of delivery, a CIO must develop an executable strategy. Unfortunately this can be a daunting task if the Business hasn't prioritized its needs or developed service level expectations. 
• Worse yet, if the Business doesn't have an internal process for prioritizing and managing its needs, projects, and investments - if it doesn't have an operational review process to insure that specific business/IT processes and systems are functioning normally it will be the CIO's job to either establish these processes or sponsor them. Many CIOs understand this situation when this prioritization does not exist - it's when the Business expects to get all projects done and keep the lights on often with a limited budget.
  
• The first discussions on priorities can be difficult. It may be the first time business and project leads openly discuss the merits of their projects. Managers may be in denial on the need to prioritize based on resource constraints. It may take multiple discussions for managers to recognize the need to invest time and resources to make system upgrades or process improvements. In these discussions, it is critical for the CIO to largely play impartial on the merits of one project vs. another, but be capable and ready to negotiate an achievable set of priorities. 
• Negotiating priorities is a finesse game. It's about demonstrating constraints without saying "no". It's about asking good questions when requirements look imbalanced with business needs. It's helping business leaders to acknowledge other needs. It's a difficult skill to master, and it must be learned and executed differently in every organization.

So in my experience, this soft negotiation of priorities is necessary first step to IT execution. Once priorities are set and the Tech team is executing, negotiation evolves to collaboration.

The Most Important Job of the CIO

I was having a discussion today with a colleague about the role of a business unit CIO and told him quite definitively:

The Most Important Job of the CIO is to Negotiate with the Business

and to be successful, the CIO should aim to spend 50-75% of his or her time working directly with the Business at all levels of the organization.

My rationale is quite simple. I've never been in a business that has the resources to do everything that it wants to do. On top of what the Business wants to do, there are a good number of things that a Business needs to do whether that's patching a system, addressing a costly operational issue, or complying with a legal requirement. Now the CIO is usually not be the person directly responsible for setting strategy or for prioritizing investments, but a CIO can make sure these steps are followed and can provide critical data around these processes. They can pose complex questions that span the activities and responsibilities of multiple teams. They can propose simple solutions to challenge leaders when the ideal solution has complexity. They can make sure leaders develop and utilize metrics to justify their approaches.

Most important, they need to insure that the business' desire to take on too much doesn't trickle down to the teams taking on these projects. Overloading teams with too many projects or projects with ill defined goals or requirements is a good recipe for poor execution. That's why this is a negotiation - a negotiation for what makes strategic sense but also what can be realistically accomplished.

Of course, once the CIO can effectively negotiate with Business Leaders, the dialogue will often transform from one of negotiation to one of collaboration. But that is the subject of another post.

Don't Negotiate without Credibility

But here's the gotcha. Only a credible CIO that has a good track record of execution and delivery can truly negotiate. Business leaders simply won't waste their time negotiating when a CIO can't deliver. Why bother? Worse, a business leader is likely to work around the CIO if delivery is a recurring issue.

Next post: On building credibility

What is Really Meant by Failing Early, Failing Often, and Failing Cheap?

What do we mean about failing early, failing fast, failing often, or failing cheap? Why is "failing" a good, positive outcome for some features, agile projects or agile delivery? Why is it needed for innovation?

Failure was once an absolute outcome. You either succeeded or failed in your business, your project or your investment. Once something was marked as a failure, it was almost beyond hope to fix it without a major "turn around" or dramatic rescue.

Failing early, fast, often, and cheap gives business and IT leaders many advantages:

• It basically implies that you've defined indicators for success or failure ideally as key performance metrics. That definition creates an alignment of goals, transparency, and process to discuss improvements.
• Failing early implies that you're taking some (appropriate) risks up front and can adjust your course while your business or project is in early stages.
• Failing fast implies that you're making small, tactical changes with easy mechanisms for measuring that you're tactics are meeting strategic expectations.
  
• Fail often is an attribute of agile and iterative delivery. If you deliver often you can accept some failures because you have a mechanism to recover, respond, and adjust faster. (Corollary: Deliver often should also encourage success often!)
  
• Failing cheap is exactly how it sounds - but it encourages the leadership team to find inexpensive investments and expressions to validate a hypothesis.
• Talking about failure openly allows teams to think offensively rather than defensively. It helps to avoid a "fear of failure" organizational culture.

By failing early, fast, and cheap, there is a mechanism to avoid absolute failure.

I like the open acceptance of failure as a mechanism to encourage smart risk taking, however, I do wish there was a better form of expressing this mindset. When I hear leaders encouraging teams to fail early, fast or cheap, I often wonder if they deliver the message correctly. Do team members understand the message as I describe above, or do they hear something entirely different? Maybe they hear, "give this your best shot, but don't worry, we won't penalize you if it doesn't work out because failure is ok". Or maybe they hear "it's ok to make errors as long as you fail early, fast and cheap". Also, even if you fail early, the right decision may be to pivot rather than abandon the current strategy (see Pivot, don't jump to a new vision and When your first product isn't selling).

Should we change lingo? I doubt it because the concept is easy to understand as long as leaders take the time to explain what they really mean by failing fast, early, and cheap.

What Could Save Media Businesses

So what will save the media industry? John Byrne's assessment of the issues are dead on

1) Print advertising will never come back. There are just too many options for advertisers today and too much pressure on rates. Sadly, success in print will be measured in single-digit declines, forever. 2) Online advertising will never offset those declines nor save print. There’s far too much competition online and far too much available inventory; and 3) Users will not pay for content, unless they’re convinced it has immediate and tangible value.

I do see a couple of plausible game changers in the not so distant future

• Tablet PC's - I do most of my reading on my Blackberry like many other commuters. It's good enough for me, and I actually can find and read more relevant content than I could with any newspaper or magazine. But while a mobile device works well for many users, it doesn't work well for advertisers yet. A Tablet PC could change this if it provides adequate fidelity for rich advertisements, a good user experience, a decent price, long battery life, etc.
• Shared Search Revenue - I agree with TechCrunch's assessment that 5 clicks free
  won't provide significant revenue to Publishers that participate. It could be a game changer if publishers form networks and force users to pay for clicks to participating sites, but this has risks of alienating users. What Google and Microsoft/Bing are showing is that they are willing to negotiate with Publishers and possibly share search revenue with them. What happens if Google shares X% of search revenue to Publishers that show up in the top Y search results? It probably won't generate significant revenue for Publishers, but it would give another source other than advertising or subscription.
• Pay for context, not content - Would I pay $3 to download a digital magazine at the airport? Should newspapers charge to access its news and analysis from 6-10am, then make it free afterward? Would I drop cable tv (and its fat costs) in lieu for an online video and news subscription?

So while the media business is falling off a cliff, there still may be a future.