Tactical Versus Strategic

During the recession many of us have been rethinking and prioritizing our goals. Mostly this is due to shortage of staff, reduced budget and lack of sponsorship. Cutting back is just a simple fact, but how do you propose a roadmap and a plan that can be delivered on? The best approach is to work with what you have and what is within your sphere of influence. So step back a moment and look across the teams and talent that is on hand.

Partnering with another team and proposing new content or new media can boost that teams visibility and value. It also provides material that your team can repackage and deliver as new programs and offers some marketing opportunities. Repurposing content is also another route, so taking inventory of what can be repurposed outright is a worthwhile task. This is a time to be creative and other groups will respond to creative solutions, since they are also experiencing the same setbacks. This is not the time to “hole up”, and your instincts may suggest retreating into a cave – the opposite is true. Take talented folks and department heads out for coffee or lunch and brainstorm. Promote your agenda and find ways for people to participate or offer better ideas and solutions to your predicament. Avoid whining, it is a time to scan and identify your allies and mentors. Be a problem solver and creative thinker, and watch others come to your aid.

Lastly, there is something to avoid. Working more and harder will not improve the situation. Working smarter will. So take a strategic view on your tactical plans. Tactically focused roadmap and execution plans on their own are not enough unless you can dovetail your plan into a bigger picture. Look for alignment as you team up with other departments and other projects. Can your work on new media or new content types help you learn what users want? Will it change your search engine plans? Can a survey or poll in combination with tactical deliverables provide insights on other planned features? Tactical achievements may help your strategic plans and improve their chances for success by defining requirements and building broad support from your tactical teamwork.

ProductCamp at Microsoft Research & Development Center

It has been a busy Thanksgiving whirlwind, but my ProductCamp update is coming soon.

ProductCamp Boston is really interesting, fun and I always learn something new. Often, it is something obvious that I never saw clearly through the chaos of constant reprioritization. I will be sitting down to review all my observations. Microsoft deserves a thank you for once again sharing their amazing digs in Cambridge for this event.

Transparency and BI

It has been a hectic few weeks, but when I last posted, I was thinking about “transparency”.  This concept is popular amongst product innovators and thought leaders and still guarded with suspicion by P&L owners and c-level execs. There are good reasons for debate on both sides of the divide. What do I mean by “transparency”. Many web applications gather business intelligence by collecting data in the background and present the resulting analytics in a near real-time stream of metrics. A good example is the stock market as viewed from Google Finance. These business intelligence tools and graphic displays of metrics are in every industry dashboard and toolset across most industry apps. I could list almost every one I have seen from HR apps, medical market research, banking, investments, telco phone charges, advertising metrics and Bloomberg professional service, of course.

Here is the issue. With growing ability to display meaningful metrics, applications can easily display usage data to their own users and BI analytics that clearly share usage patterns and community segmentation. The leaders in this trend still tend to operate on the fringe, with more “edge-y” sites embracing this transparency of usage, segments and categorization. They tend to be youth oriented, R-rated or a niche play. Larger sites and public companies tend to see BI data as competitive intelligence and guard all usage metrics closely. I am beginning to see things differently and sense there are benefits to being more transparent with metrics.

When you consider the growth of reader ratings, Digg recommended content, and user-generated advice then the trend is moving towards a more transparent model. Social networks and social marketing that use brand oriented communities have stepped lightly forward, cautiously. In the end people vote with their feet, irregardless of marketing’s best intentions. These short-term approaches and early ventures may be cautious with published data. However, most applications, social networks and communities may benefit from a more transparent approach to who is online, why and to what benefit.

Embracing this transparent approach means tolerating “snarky” remarks and complaints, as well as, good ideas and suggestions with the capability for the users to vote for what they like best. This often works for one reason alone. There are monitors and resources standing by to react decisively to the input. Creating this type of fishbowl only works if it is dynamically “oxygenated”, and that means active users with internal counterparts who will quickly respond with action plans and communicate back to the users. Transparency also means calling out the trends and summarizing what is important, even if some users don’t want to go along and wish to stay in smaller niches within the site. It’s a democracy to a degree, and in some regard, every niche must be catered to, but sometimes the course is a populist vote that makes a decision to move in one direction.

For example, I worked on a dashboard that had excellent segmentation of the users and a breakdown of the topics of discussion with many options to filter and chart the health of the community. These dashboard metrics were internal and shared with clients, but not shared with the users themselves. Why? at first glance, the effort to share metrics and BI data was not a business driver. However, I believe transparency of metrics and engagement would further promote community participation and speaks to the company commitment. The most important aspect to tackling this effort, would have been fast follow-up and a clear communication of requests, company actions and scheduled delivery. Looking at Facebook the analytics pose a more difficult question. Would a metrics showing the number of 40+ users cause younger users some angst? Would certain metrics be shared and thus others avoided. The answer is yes, and deciding what and how it will be supported, critical.

When tackling BI metrics and analytics, I think the time has come to consider what the benefits might be of openly sharing the metrics with your most important asset, the user. Some users will find published metrics and analytics the perfect tool to become further engaged. Using charts and graphs to drill into new interests for themselves within the site and to share insights by suggesting improvements and site innovations.

Trends in Innovation…

This post is more stream of consciousness than critical analysis, but I have been reading a lot of articles lately. As any startup guy, I have my “water cooler” observations and a few predictions to share.

Social networking with mobile apps, GPS enabled iPhones, and all the buzz and clutter of gadgets and HD video , it can be overwhelming. However, navigating through the press releases and new product leaks produces some interesting trend lines. This is not an attempt at a “magic quadrant”, but if we did draw the lines on an axis of time to market and product maturity, we would have assumptions about how and when these lines would intersect, and what product innovations might result.

1. The old media models are in churn and have been for some time now: education, publishing, television, advertising and music/ media, all the rules are being rewritten. Ad revenues may be way down, but down from a ridiculous high, and are more normalized.

RESULT: COMCAST is looking to buy NBC. Bloomberg bought Business Week! Sony is cozy with Google, looking to dominate the eBook market. Media, Publishing and Music must consolidate and opportunities will present themselves at an accelerated rate. We will see more mergers and acquisitions. Ad revenue biz models (especially for web ventures) will continue to decline in popularity, in the long run they are not viable on their own. Technology companies that improve targeting and campaign efficiencies will still have a market opportunity, since costs must be cut and productivity improved.

2. Well, just about all forms of what could be called “express” content and micro-production are spiking and I love it. It’s all personal, fast, relatively cheap and the quality acceptable. You can short run T-shirts to business cards with personal publishing of magazines, books, blogs, personal printing, video, on-line training, college credit on-line and alternative sources for all your news and content.

RESULT: Micro-personal is in, and products that approach feature sets with this fact in mind will do well. This is B2C of course, but B2B also if you look for it. Many recent startups focus on narrow and personalized approaches to B2B that are configurable and leverage many B2C social media tools, but for business purposes.

3. Software has gone to “managed services” or SaaS, and Cloud computing will further expand the capability and flexibility of software on-demand.

RESULT: This is an interesting trend and so nascent that new products & platforms will adapt to leverage the mobile users that access the “cloud” when, where, and how they want to. The new Android app “Decaf” is just a small example of what is coming.

4. Subscription models are having a resurgence against the “free” models and more micro-payment concepts are coming into play, we are now accustom to a simple iPhone app or music/ video download for a small fee.

RESULT: Netflix is developing this streaming model a la Comcast on-demand delivery instead of their mailer system. Kindle and other eBook readers are also exploring alternative micro-models, and this market is in play with many looking to dominate it over the next few years. Small is hot.

5. Many of the new mobile technology trends leverage social networking combined with GPS, such as Loopt and uLocate.

RESULT: Mobile phones are more like the personal devices we first imagined when the Newton was released. I know someone for example that sent 2700 text messages in 30 days, 400 in one day alone, never mind all the photos and video produced and sent. The users are “twitter enabled” as they text more and more. Facebook and Twitter are on a collision course or is it just me? I see lots of new products coming to market over the next few years. Devices are changing and merging functionality, and hybrid devices will come to market in 2010 as the rumor mills have predicted.

6. Laptop trends too are changing with the leak of iTablet and MS Courier devices and netbooks with Android OS. These all will be out next year, some 3G enabled.

RESULT: These new PDA’s could make for a “killer app” for the mobile platforms we already know. This trend also highlights the move of iPhone from B2C to the Enterprise. The inroads have been made and the iTablet could be the perfect solution for enterprise apps.

7. Miniturization, memory and battery life continue to improve and so do the technology platforms which leverage these improvements.

RESULT: So the convergence of devices that these improvements initially brought can continue if the costs of the new products can be managed in a recessionary market.

8. Monetizing social networks, twitter’s explosive growth, crowdsourcing techniques and private networks, these growing apps are going mobile and folks are now leaving their laptops at home.

RESULT: There is a growing market for more mobile apps. The consumer markets are leading with new product innovations and the enterprise will follow over the next 3 years.

What’s going to happen in 2010,  what features go on which platforms, and what are the big ideas floating out there?

If you take a sneak peak at iTablet there is a market for such a mid-size mobile device. Apple’s new 10-inch iTablet/ iPad estimated at $800 with a February launch? These may come head to head with the Android netbooks that are even less pricey? I am certain Apple has fears of cannabilizing the iPhone/ Macbook market, but in fact it could be a marketshare winner. The convergence of mobile features/ apps needs a larger screen for documents, books and multi-media content and there may be a iPad 3G option, or so the rumors say. There is a coming surge of business applications for the iPhone platform and a few startups are focused on the market opportunity.  Add Skype on this mobile platform and a long battery life, incorporate photo and HD video ability and an eBook reader and then every student will want one.

Where I think the MS Courier may have gone wrong is that it really is an electronic notebook called an “infinite” journal in the press, and it is missing the app community focus and mobile device capability of the Apple design. Android is still out there and its free, but yet to make its mark. Check out the Android apps though. Android apps are smart and slick.

I think the consumer market opportunity is clear, but few are discussing the business market and it is competitive, with complex procurement, approval gates to navigate, to penetrate, and to win. The iPhone and iTablet could position themselves as a enterprise business solutions provider with a proven platform better suited to enterprise apps and supported by additional device options. Timing is a critical factor here in these observations. The business market must be ready to invest in new solutions, but with a longer term set of productivity and ROI milestones over 3 to 5 years.

Legal and Product – a Partnership…

Product Management does often work with Legal on product launches, license/ subscription agreements, and IP. Some Legal projects include third party licensing inventories, or review of changing legislation that may affect content distribution or compliance regulations. Nonetheless, most Product teams have a friendly, but narrowly focused relationship with the Legal department. Frankly, many Product teams are concerned about intrusive Legal review and scrutiny of product details. If you have ever undergone such exams, there is some trepidation when engaging Legal.
However, Legal teams combined with Product can uncover ways to improve and speed contract discussions, signatures and closure. Legal teams also have insight into Sales, and can provide a perspective on deals and process improvements where Product can deliver solutions. In product speak, Legal often has clear and actionable requirements that are achievable and affect the bottomline.
Here are a few Legal partnership examples that worked. My first Legal team helped define legal tech specs that could be attached to contracts as core deliverables of the product. This was helpful in clarifying the services part of the contract from the core or configurable features of the product. These were updated regularly and kept on file in Legal along with a complete inventory of licensed 3rd party products. Good stuff and as Managed Services/ SaaS blossomed this partnership led the way in structuring an effective subscription model.
Another example took me by surprise. I had been working with Sales to close a number of deals and we were barraged by last minute technical Q&A. I was working with different sales reps and SEs and the questions were random and broad ranging. Legal called me in at the end of the day to discuss some product details to prepare for a closing call. In chatting with her, she began to explain the recent developments in the closing process. We made the connection between the questions, Sarbanes-Oxley and SAS70 certification. BANG! I suddenly got it. With some research, we came back with an action plan for documented operational guidelines for our Managed Services and started on a SAS 70 certification project and EU regulatory compliance. Working with Legal, we made contract references to these published docs and certifications as they were delivered and updated. This greatly improved the final closing steps as the check boxes were first defined and then supported by materials that could be shown and reviewed. Significant education of Sales and SEs was required, but final closing discussions and independent 3rd party audits became smoother and faster.
Sales could not clearly articulate all these needs to Product, but Legal could provide the high-level requirements and Product then identified and provided the solutions. All Legal and Product teams are different, and in-house Legal teams are ideal when building a true partnership. I am not saying that Sales and SEs should be ignored, but that balancing the discussion with Legal can reveal the true needs and set you on track. Legal and Product together can create real value for everyone.

The need for Product Managers?

In the venture backed startup world where SaaS business models are prevalent, there are management teams that question the need for Product Management personnel. Product managers appear to be working across so many functional areas that perhaps each of these departments could take over a portion of the workload and reduce the need for Product Management all together? Web analytics have also improved and there are now teams of data wizards and DBAs that munge data and present user research findings.

Behind the scenes, there are also other forces at work. Product Managers are often held accountable for the challenging and conflicting objectives of different departments. They are also often “foils” used in evaluations when senior management is called to action against declining revenue projections. I am a realist in these matters and aware of the complex politics at play. However, Product staff do have defined responsibilities across many areas. They do have accountability to Sales, but are often judged by sales outcomes that they may have little direct influence over. However, to keep the game fair they require access to win/loss information which is often closely guarded by Sales teams. As an aside, many organizations I have worked for do an editorial review of the win/loss analysis and then provide a “cleansed” version to the Product team. As you can imagine, these win/loss statements generally restate that the product line lacked competitive features which lead to the loss and drop in sales. This is when the teams are not well aligned and the partnership deteriorates. Product staff is often wise to these tactics and will quickly assess if the role simply requires “whack a mole” prioritization, understanding that predefined criticism with a heaping helping of blame are tacit to the role itself.

There are several reasons why these conversations about the need for Product Managers are occurring now:

1. Cost reduction and FTEs:  seasoned Product professionals are expensive when the FTEs could be allocated to Engineering instead.

2. Most executives really do not have a holistic understanding of what Product Management is, and have largely one-sided experiences of Product Development, as either market focused, P&L owners, sales support, development managers and product owners, or “Voice of the Customer” advocates. ( In the best sense good product managers are ALL these things and the “glue” that holds many organizations together.)

3. SaaS products and related services have more data and web analytics teams than ever before, marketing and sales are now wondering if the “voice of the customer” has been replaced by good analytics coupled with a Gartner or Forrester partnership for trend analysis and competitive information.

4. Redefinition of Product: product leads, product owners and product management/ marketing roles are blurring the lines and roles that Product is playing in different organizations.

5. Control and fiefdoms, most product development teams function independently within Engineering or Marketing, with staff reductions there is an opportunity and thus a struggle for control in politicized organizations, and functional reorganization gives many aggressive execs a chance to seize control of areas that were not previously accessible.

I could tackle these one at a time, but some are clear and easy to understand. Let’s look at the trends. More data is available then ever before and significantly faster and more specific information. Google, Amazon, Apple and many others are building and delivering products and entire platforms built on this fact, but it is prevalent in all web ventures and a differentiator for many SaaS startups and social media sites. When you take this trend and combine it with Agile teams of Product Manager roles and Product Owner roles, plus the added off-shoring of many resources you can see the resulting confusion. Where do we flatten the organization? From the middle, right? Great idea in the short term, but what happens longer term? This is playing out right now in many organizations and I suspect what we will see is two-fold.

Simplifying, Product Managers provide two key functions that no one else is directly chartered to execute. One is to ruthlessly prioritize weekly by scanning across all the drivers & stakeholders in the market and across the company. The other is the product vision and resulting product roadmap, by advocating for the users and being the true “voice of the customer”. Sounds simple. However, web analytics alone cannot provide this, it can only support or refute the assumptions. Marketing can absolutely contribute to the product vision, but not the rest, since they are often operating from the “blueprint” and not actually living in the house. Many other groups will try, but the others are measured and motivated by incentives that distort their ability to execute Product’s unique charter.

Two side effects tend to occur as a result without product management in the balance. One, organizations will tend to drift towards a sales-driven model that is often seen in agencies and in enterprise products having a strong services model for integration or customization components. For SaaS products there is a rapid growth in over-selling and quickly operationalizing with temps and partnerships as much of the delta as required. Basically, the Product dial moves from strategic over to tactical fairly quickly. In some cases, an individual will take the role of Product Manager and try to perform the function without the title, this works for a while, but generally these people burnout trying hard to do the work without any real authority.

Second effect, the split screen organization. The engineering teams start running the “sausage factory”. As direction comes down quickly from Sales and Marketing, the engineers to keep pace must start to do their own prioritization and almost all their own user stories and requirements work. So they work to meet deadlines and do what engineers do best, “make stuff”. However, there are no longer any checks and balances in place and what is really being worked on becomes less and less transparent. To compensate and guarantee delivery, management teams have to institute more reviews and demos that the engineers must now work on and attend, and thus spend less time coding. While what is really needed becomes a matter a “luck” or more iterative trial & error, therefore more meetings and demos, and more refactoring. The organization starts to split into two squads, those that want good stuff now and those that are busy trying to figure out what it is and deliver it fast. Either senior managers start to do the Product Management work immediately to correct this disturbing trend, or the battle lines start to show and motivation drops off quickly amongst the engineers.

I think these two effects are extreme examples, and most organizations without a product management function can hobble along for sometime with various folks pitching in to fill the gaps. The most common example of this approach is organizations letting one or two Product Managers remain onboard to do the work of an entire department, and basically have them keep the lights on for as long a possible.

Cherrypicking what works…

I attended a panel discussion sponsored by Rally Software this month. The panel was composed of individuals from different industries, each holding quite different roles in their organizations. They each contributed to a discussion of Agile and its benefits and challenges through the lens of their respective roles. This was probably what made the dialogue intriguing for me. The executive-level presentations made sense, and they focused on metrics and strategies for management approval, the buy-in and then follow-up phases, reporting on the velocity and productivity gains Agile can bring to product development.

However, the technically focused management reminded me of bad habits that are often overlooked in the rush to see rapid productivity improvements. I cannot present all the materials here without permission, but I will reiterate the basic message (and thank you Heather for this insight)…
Agile as a process is a collection of practices that works as a “collection”. Each practice is coupled with, and balanced by, the other practices. Sort of an ecosystem, were the inter-dependencies result in success or assured extinction for all. New practitioners, startup ventures, pilot programs and specific industries all tend to adopt Agile in a primordial way, by collecting the most relevant practices and adding them to the “soup”. Teams build an Agile “soup” based on need and how much change and training they can absorb quickly. A very common sense and practical way to get rolling with Agile. This is why training and coaching are so important to new adopters, it is often the missing key to success in these lean, budget cutting times.

Nonetheless, as organizations grow and the process matures, managers want to add to the maturity of their Agile practice by “cherrypicking” additional practices and adding them to their Agile “soup”. Here is where things can go awry. The practices and the disciplines are not intended to be mix and match. As stated in earlier posts, this is where “hybrid” approaches tend to evolve and teams try adding in waterfall practices and milestone gating steps to resolve where they are having issues. This is not wrong (but nor is it Agile). These modifications and “cherrypicking” of additional practices is where a clear understanding of Agile is required. For example: There is a growth in the number of teams and an explosive growth in the interdependent nature of the work being done, the group decides to add a “Scrum of Scrums” to have better team oversight. Here the group is adding a practice that fits into the Agile framework and upholds the ecosystem. Another example: A new team is added to work on platform services to be used by all the teams, this new team is technically strong and very dedicated to delivering on time to their co-dependent team mates. They breakdown all their user stories and pre-plan each in detail and discuss all the tasks and tests required. When they are finally certain they understand all the work, they commit to the stories and start the sprint. Unfortunately, this is waterfall estimation at a task level and not Agile. Even though the team’s intentions are good, they are operating as a rogue waterfall team compared to the other Agile teams by doing extensive task level estimation work prior to committing to stories. The other risk is that this team may be blocking the goal of “collective code ownership” as they focus and specialize.

Returning to some of the codependent practices, here is a short list of elements that work inter-dependently in an Agile ecosystem:

• TTD (test driven development)
• Pair programming
• Collective Code ownership
• Continuous Integration
• Simple Design
• Refactoring
• Automated Acceptance Testing
• Customer Involvement
• Adaptive Planning
• Sustainable Pace
• Small Iterations and Releases
• Continuous Feedback
• QA Involvement
• Empowered Teams
• Eliminating Waste
• “Done Done” Stories
• Estimate-able Stories
• Iteration Velocity
• Inspect and Adapt (Retrospectives)
• Whole Teams

When teams are inspecting and adapting (often through retrospectives) then helpful practices may be added or may evolve. However the panelists were clear in this message,  when “cherrypicking” to grow process improvements it is important to recognize how the ecosystem works as a whole and select component practices wisely so as not to disrupt the entire system. Remember to focus on complementing the practices the team has successfully adopted and reflect of the health of the ecosystem.

Sizzle and release planning…

As many of my teams will acknowledge, I prefer all releases to have a feature or two with real sizzle. The name of this blog is no coincidence, features do fall flat if there is no moment of surprise or recognition. I love it when users say, “you actually heard me?” or “yes, that is what I meant, but I could not explain it.”  This can be challenging with Alpha or Beta releases, and more so when real platform work needs to get done to support complex features, such as data mining and automated BI dashboard functionality.  I treasure a custom mug from my beloved “Darkside” team that reminds me daily of how I pressured them to give me more “sizzle” with each monthly release.

Here is where a UI designer can make all the difference, and if you work well together, she or he can take functionality and make an experience that “automagically” delivers results. It can be anyone’s vision that connects the dots and many folks have surprised me with brilliant and simple ideas, but presentation layer makes or breaks that Disney moment.

I am still a friend to Ops, Support and the DBAs and end up doing lots of hard work to deliver TCO features that only the backoffice cheers about. However, my inspiration often comes from the clients. When you get to know them, they are often suffering alone in cubes, unheard and doing the most crazy things to get around processes that do not work. I have seen people get up and walk football fields to avoid logging in, or endlessly going through old emails to retrieve old links because of bugs that were never fixed. Some offices out there are still living in 1972, glamorous and wealthy companies in Manhattan with employees carrying the latest gadgets and dressed in the latest fashion are working on software systems the equivalent of an 8 track tape cartridge playing the 5th Dimension.

I digress a bit, but these shocking moments did inspire some evil pranks in my more youthful consulting days. I was working to move folks in the US from an old publishing system to a state-of-the-art desktop publishing and digital pre-press system. The cool new applications and hardware were coupled with users endless questions about the asset tagging of all the equipment. It drove me mad. Finally in frustration, I started telling the users that the asset tags monitored overheating and radiation, so please call support if you notice a change in the color from white tags towards red, which indicated possible risks. Of course, the support desks were flooded with calls of asset tags looking “reddish” and I learned my sense of humor was not widely shared by my teammates.

War stories aside, if sizzle is needed there are a few approaches that work well. Creating user stories explicitly for design tasks to occur well ahead of releases, this has worked for me. You need a strong design team, and one that can build click-thru HTML prototypes is desirable. Keeping this team a step ahead, allows the ideas to percolate in advance of the code base, easily transforming the story backlog and the upcoming release themes. Without such resources, stories can still be written one sprint/ iteration ahead and the wireframes and the HTML worked out in advance. It means splitting the parent story into two child stories and putting them into two separate sprints. This works well when socializing the design requires a week or two of upfront iterative work (to get the developers, architects and management on board).  As political as this sounds, it is often a reality.

All teams are different and many founders, VPs and managers want to own the look and feel, and therefore also own the sizzle when it suits them. This is okay, but it is very important to recognize the subtle connections when client commitments, sales deals, RFPs, prospects being shown mockups, and other leaks or promises are occurring around your planning. Own it by being candid, clear and upfront about commitments, uncommitted concept stage work and any resulting risks. This includes stating the “NFW” features, so folks also know what cannot and will not be delivered in upcoming planned releases.

The trend towards hybrid product management…

It’s hard to define a trend without real metrics to back it up, but from talking to several Product Managers across several vertical markets, I am starting to see a pattern. Here it is.

First, Product Managers and Product Marketing Managers were among the middle management tier cut out of most organizations with the lay-offs of late 2008 and throughout 2009. As these managers departed, the growth and hype around Agile Development continued to spike. This Agile Development movement already had real momentum, don’t get me wrong, and the BPMA, Boston ProductCamp and New York’s ProductCamp held many seminars and panel discussions around Agile Development. As this lifecycle process continues to gain adoption, the PMs and PMMs in most organizations are simultaneously being whittled down and the traditional roles of Product Manager, Marketing Manager, Product Owner and Scrum Master are starting to “blur” and in some cases collapse all together into a single individual. I know more than one PM scrambling to “do it all” by keeping all the plates spinning (and probably fearing for their job while spinning their priorities).

It is unfortunate, because in this new product “circus” many organizations think they are adopting Agile Development when all they have really done is put up the tent and then placed all the same groups, processes and behaviors under the “big top” while looking to product development to make it work as a profitable enterprise. I have been out talking to many companies since January and many are engaged in a hybrid approach to Agile, writing requirement docs and specs and often missing QE and KPI requirements all together. Hybrid approaches are not right or wrong (they can work), but I think the initial results from adopting Agile, the velocity and metrics from such random experiments are misleading and likely cause inaccurate conclusions. A better approach in my opinion, is to let one team actually pilot Agile with respect for the required roles, backlog development, user stories and a proper retrospective, and I do think it is more effective to let the team decide the duration of such a pilot program. One of the benefits is that the organization as a whole gets to learn how to do Agile correctly and understand what it means.

Nonetheless, the missing piece in many of these experiments is that management does not think they have to change, nor does Sales, nor do the Clients. The fact is everyone must change and change often and frequently update each other. However, that is exactly how participants get what they want faster and get to refine what they actually do want in the process.