Virtual networks of professional agile coaches and trainers is good place to pick up some most thoughtful and provocative agile discussions. The most reputable networks that I know of, and happen to belong to, are the communities of: Certified Enterprise Coaches and Certified Scrum Trainers (both, from Scrum Alliance), and Candidate Large Scale Scrum Trainers and Coaches. These communities are great because there we continuously share our experiences and learn from one another.
The summary below is the result of one such in-network discussions that spans in duration for more the a year. It is focused on in-class training experiences and highlights – some of the most common challenges that we encounter with our students in pre-, in- and post-classroom situations. Some of our observations are specific to internal classes, some – to public and some – to both.
Below, are some of the common challenges with Agile Training that we face:
- Training “Wrong” Attendees with “Wrong” Intentions
- Training “Certification Collectors“
- Influence of Past Quasi-Agile Experience or Misguidance
- Lack of Pre-Training (Self-Study)
- Attempts to Change Training Content to “Conform to Reality”
- Attempts to Steer Training Content towards “Unique Situations”
- Requests for Exemption from Training by “Special” People
- Lack of Classroom Participation
- Too Much Reliance on Training Materials
Training “Wrong” Attendees with “Wrong” Intentions
At times, we get training attendees that have never held agile roles (e.g. ScrumMaster, Product Owner, Team member), … nor did they ever have an intention to do so.
While agile education is recommended at all organizational levels and for all horizontal structures (perhaps, with different focus, depending on audience), what is sometimes observed is that certain types of individuals show no signs of desire to truly understand to further implement newly-learned agile principles. Instead, their true desire, seems to be, in understanding agility concepts just enough to be able to figure out a way of creating “anti-dote” against them. Typically, this is seen with individuals that are concerned with their own role security (not to be confused with job security) as it frequently gets challenged in agile and lean organizations (includes processes, tools and roles).
This situation is rather difficult to control in public classes, where any individual who pays a fee, can attend. However, it can be (and should be) much easier to control with internal training. By requesting class attendees to come in ‘clusters’, as hands-on technical teams that share work already, accompanied by their respective business counterparts, trainers can ensure that right people are gathered together in the same classroom, at the same table, for shared learning, collaboration, and simulation exercises. This is the most effective way to ensure that in-class learning will retain its momentum, when people go back to their work areas and start implementing newly gained knowledge in practice.
It is important to note that for any trainer who is planning to engage with trainees for a longer period of time and coach them, it would be especially important to have right people in the room during training – together.
Training “Certification Collectors”
It is not uncommon to see individuals that come to training with the main goal to add another trendy certification to their collection. This is mainly fueled by job market demands, as hiring companies create job requisitions and look for a “soup of certifications”, sometimes, asking for most awkward and, sometimes, conflicting combinations. For example: “A candidate must have CSM, PMP, PMI-ACP, SAFe, PRINCE2, etc”. Most of such jobs are usually poorly described and contain erroneous statements about actual role expectations.
This situation has been observed much more frequently in public training courses, where individuals pay their own money to attend. Less so, this has been observed with internal training, where students do not pay their own money to attend (nor do they get certified). As such, their eagerness to maximize ROI from attending aa class is much lower.
Also, as a side-effect of this unfortunate pattern, blind pursuit of certifications by non-practitioners who don’t have any intentions to put their learning to practical use, also dilutes meaningfulness of certifications in the market and adds even more confusion to hiring companies.
Influence of Past Quasi-Agile Experience or Misguidance
Some individuals come to training after prior “agile theater” experience. Please note that in this post, the emphasis is made on specific cases, when prior agile exposure was of low quality and had created confusion or conflict with new learning.
Bad agile experience may come in various forms. For example, poor agile implementation “on the job”- often due to a complete lack of training and misguidance by management. Another example would be previous low-quality/misleading agile training that was delivered by unqualified guides. The adverse effects of these types of wobbly foundations are observed equally frequently with public and private training.
It is worth mentioning some well-known sources of unqualified guidance:
- Vendor companies that lack internal agile expertise or track record of teaching. Historically, such companies have done mostly staffing/recruiting or management consulting of some sort and just recently decided to step into ‘agile arena’ in pursuit of additional revenue (pretty common these days). Such companies “get lucky” when their is long-standing clients pull their names off a preferred vendor list and ask to fulfill agile staffing needs. Usually, hiring companies that use this approach get exactly what they paid for :).
- Internal employees that have been promoted/fast-tracked into trainers or coaches to fulfill a growing internal company demand for agile guidance. Such individuals, most of whom do not have any prior field experience as coaches or trainers, are too restrained to existing organizational norms and standards: they are not reformists and challengers by mindset; they are conformists and executioners. Thus, in classroom settings, they present “by the book”, at rudimentary level and steer their followers towards “…this is how things are done around here…lets conform our Scrum to constraints of our organizational design and our internal best practices…”. Such agile guides are not very effective in handling out-of-the-box situations or addressing serious inquiries that require deep understanding of organizational design and system dynamics.
Internal agile trainers that have been more successful in their work than their peers, usually position themselves in a way that they have, first and foremost, ensured their own security and operational safety that is required to drive organizational changes from within. Secondly, such individuals also have a very strong connection with external professional circles of trainers and coaches, though which they explore horizons of their learning beyond boundaries of a single organization and continuously hone their craft as trainers and coaches.
Lack of Pre-Training (Self-Study)
Almost any trainer will appreciate having in her class well-informed students (a.k.a. “educated consumers”) that have done recommended preparatory self-study before attending training. Self-study helps normalizing basic understanding of concepts and level-setting students’ expectations from in-class learning. It also, potentially, reduces the amount of basic, rudimentary questions that unprepared students often ask in class: about terminology, conventional abbreviations, jargon, etc. By spending less time on explaining basic book definitions, an instructor can spend more time on collaborative activities, role-playing, discussing real-life simulations and doing practical exercises. This case of low preparedness is more frequently seen with internal training, where a company sponsors an event (even, when an external trainer is hired from outside, employees don’t pay from pocket) or training is totally free (done by an internal trainer). Just like in the situation described above, students’ desire to maximize ROI is lower than in public training, where people invest their own time and money to attend.
Attempts to Change Training Content to “Conform to Reality”
- “Is it possible to shorten our training from 2 days to a few hours?”
- “Can we conduct training just for IT people, since it is hard to justify to our business partners why they need to be away from their desks for a few days?”
- “Can we conduct training just for business people, since our IT people are already well-trained in agile, “doing stand-ups” and using Jira/Rally to track time spent 🙂 on tasks and they see no value in going through another training, alongside with business?”
- “Can we review training materials upfront, to make sure that we don’t waste any time on topics that are not relevant to us and ensure that we conform to our existing organizational reality (philosophy, norms, rules)?”
These types of requests are almost unique for internal training arrangements. Frequently, they come from first- and mid-level managers that get their marching orders to “do agile” (a.k.a. “support-in-spirit”) from senior leadership, and while orders are given, the empowerment to make sure that things are done properly– is not there. Such corner-cutting and artificial scope reduction has its own reasons. Here are some of them:
Sometimes, agile training is perceived by both: attendees and their managers – as an easy way of meeting personal objectives in order to receive good performance appraisals (when students are asked in class why they are there, they frequently respond that “…it is in our personal development plan and our management wants us to do it, because everyone else is doing it…”. [Author’s irony: “if everyone was jumping off the roof would you do the same?”]. There is no clear understanding, purpose, vision or goal. There is no clear strategy on how to put new learning to work, after attending classroom training.
There are other times, when attempts to change training content are caused by a desire to circumvent or avoid sensitive topics that could be perceived by some as politically-incorrect implications of organizational dysfunction. For example, topics about harm of performance appraisals and monetary rewards, weaknesses of conventional budgeting, inappropriateness of old methods to procure for agile roles (e.g. product managers, T-shaped developers or agile/technical coaches), ineffectiveness of waterfall requirements in agile product development, shifting control and responsibilities form first-line management to teams, etc.). In these situations, agile training might be reduced to a discussion of “best practices” (agile tooling, metrics collection, agile status reporting, etc.) or reviewing some sort of an internal agile guide for best practices that usually comes in a form collection of publicly available, commoditized (internet) information. On the other hand, there are situations, when internal agile training turns into a battle field between people, whose hidden friction and conflicts of interest become more obvious because of agile topics and associated with them transparency.
Attempts to Steer Training Content towards “Unique Situations”
Somewhere like the above, this case of uniqueness is more frequently seen with public training, where people come from different companies and pay for training out of their own pocket. While their intentions to get “more bang for buck” are good and well understood, sometimes, methods are not. There are instances, when students attempt to steer discussions towards their unique situations at work, by frequently interjecting with inappropriate comments or asking an instructor to reflect, in real-time, on their personal work experiences. If this happens too frequently, it becomes disruptive for other students and reduces effectiveness of basic learning for everyone. It becomes a trainer’s responsibility to ensure that special cases and real life scenarios are reviewed at appropriate times, preferably, with participation of other students, in team break-out sessions (could be also facilitated by a trainer). Such cases of uniqueness are not as frequently observed with internal training because there is much less variance in situations within the same company.
Requests for Exemption from Training by “Special” People
There is a fundamental difference between support- in-spirit (a.k.a lip service) and true, genuine hands-on involvement and support-by-action (a.k.a. gemba). Unsurprisingly, there is a shared belief among organizational coaches that: “…a coach can take an organization in its agile journey only as far as an organizational leader is willing to go…”. It is imperative that senior leadership that is behind agile transformation is well informed and educated. While content of agile education for senior leadership (executive training and coaching) may differ from content taught to feature teams, ScrumMasters and Product Owners, it must be delivered as the earliest phase of transformation, to prepare seniors for inevitable organizational changes: structurally, culturally, processes -, norms – and values-wise.
Unfortunately, there are many cases when senior leaders excuse themselves from agile education. They delegate this critical activity to more junior people beneath. Soon, this leads to misalignment and disconnection between teams that are trying to implement agile changes and senior leadership that is trying to effectively support the effort, but cannot – due to lack of understanding of systemic and organizational implications.
It is a rarity to see senior leadership attending public training – they just find it too difficult to allocate time for this external activity. With internal training, things are somewhere better, but not by much. On occasions, senior leaders will attend initial part of agile training, and try to motivate their subordinates by personal example. While it is somewhere useful to create initial momentum, it is not sufficient. As a rule of thumb, having a senior leader sit though an entire experience of in-class learning that includes collaboration, system modeling and practical exercises, alongside with a feature team developer or product owner, is extremely rare. As a result of this, leaders leave with superficial knowledge and limited understanding of what their teams will be experiencing on practice.
Lack of Classroom Participation
In public training, it is hard to attribute lack of students’ participation to any specific cause; it is rather situational. Factors may vary from student’s disinterest in a topic (e.g. a person attends only for certification, as described above) to an instructor’s inability to effectively engage with a class, …to anything in-between.
With internal training, however, the situation is slightly different. Here, in addition to a wide array of factors, suggested above, there is an additional important factor of individual safety. Existing organizational structures (e.g. reporting lines, chain of command, seniority) may seriously influence in-class environment and dynamics. Junior folks may feel unsafe and act submissively to others, whose seniority is higher, either by reporting structure or by experience. It is not uncommon to see first-line managers and team leads attending internal training, alongside with their subordinates and more junior co-workers, and dominating in classroom by trying to set a pace and tone. What sometimes worsens a situation even further is that, inexperienced internal agile instructors that are also a part of the same organizational structure, are not able (or not willing) to control in-class dynamics to ensure safe and democratic participation by students: they lack their own personal safety and hesitate to put a hard stop to misbehavior of empowered bullies.
Too Much Reliance on Training Materials
This is probably one of the most difficult paradigms that is hard to break: there is often so much reliance on documentation that goes as far as violating the second postulate of Agile Manifesto. Most commonly, this is seen in internal training, at companies that mostly rely on their internal ambitions and self-confidence to become agile. When it comes to internal communication or information sharing, employees are accustomed to lengthy, “high-density”, corporate-style presentation decks. They carry this experience into agile training, where now it becomes their expectation of what agile training materials should look like: they look for lengthy pages of instructions and execution plans.
Speaking of training materials, it is relatively easy to distinguish training materials of a professional trainer and materials produced by an internal agile champion, who has little experience in the field. In the former case, materials are usually light in verbiage, more illustrative, graphical and entertaining; they mainly serve as conversation enabler and a “pacer” for an instructor. In the latter case, materials are very data-dense, fine-printed and require intensive reading. Unsurprisingly, when students attempt to follow pages of heavy presentations, they disengage from their classmates and instructor. This further reduces learning and information retention. This is also a primary reason why there is so much reliance on slides post-training. Students mistakenly believe that what has been presented on slides is a prescriptive set of executable instructions. Upon exiting “deck-driven” training, people end up ‘renting’ decisions that were suggested on slides, instead of deriving and owing their own decisions. Instead of leaning more towards experimenting, inspecting and adapting, people look for directive guidance and “best practices” from a trainer (whose experience might be also questionable).
A few classic erroneous requests that thrown at internal trainers:
- “Can we review training materials upfront so we can evaluate relevance of training to how we work today, so we can decide if we should come?”
- “Can we be excused from training but review training materials instead to get up to speed?”
- “Can training materials be finalized and standardized across all current and future training for all teams?”
- “Would it be OK if we joined via audio or video bridge and closely followed training slides, instead of attending in person?”
What some people also don’t realize is that today, the best training/educational information is an absolute commodity and it is freely available on the internet. Today, a heavy training deck has practically no intrinsic value because it is, most likely, a digest of books and articles created by others with a lot of copy-pasting involved (often, plagiary). From a standpoint of a professional trainer or coach: if someone is looking for so much reliance on training materials and execution scripts, they may just purchase a really great agile book and read it on their own, instead of coming to class.
Challenges with training (both public and internal) may cause further downstream adverse effects, beyond classroom:
- For public training, this may potentially lead to bad reputation of a trainer or give undesirable publicity to his/her course value
- For internal training, especially in situations, where it is followed by longer term coaching (could be also done by the same person that delivered training if he possesses coaching skills), this may lead to inability to effectively assist a team in their agile journey.
Frequently, HR topics find their way into Agile Communities and almost always become heated discussions. Recently, and again, one of such topics was raised in the global community of Coaches and Trainers.
Truth be told, HR norms and policies are a direct reflection of organizational culture (also, corollary to structure) and very much define human relationships within an organization. This is why, very often, the “R” part of HR is referred to as “Relationship”. A few weeks ago, at 2017 Business Agility, held in NYC, there was a strong reminder about this, by Fabiola Eyholzer.
There is a widely shared belief that the historical meaning of “R”, as it was originally defined: “Resource” – is no longer appropriate. Or has it ever been?
To refer to humans as Resources implies that people are inanimate objects, machines, goods or services that are simply acted upon by more intelligent resource managers. But resources do not think, do not take initiatives, do not mature and do not self-advance. And humans – do. So, how can humans be just resources? “Resource” – was probably an accurate description of a working human in the early part of the last century, during the Industrial Revolution, in the era of Taylorian Management (F. Taylor summed up his management efficiency techniques in his 1911 book “The Principles of Scientific Management”). Back then, when most value of humans’ work was in their mundane, unskilled physical factory labor, there was a strong belief that decision making (done by higher-paid skilled management) and decision implementation (done by low-paid, unskilled laborers) – must be clearly separated.
However, in the 21st Century of nanotechnology, artificial intelligence, nuclear biology and galactic explorations, should humans still be considered as resources, or are they rather humans?
In agile organizations, where self-organization and self-management is one of the fundamental pillars of success, referring to humans as ‘resources’, becomes even more misleading. It would be very inappropriate to consider a highly skilled, cross-functional scrum team member, who is expected to experiment, improvise, inspect and adapt – as a resource. It would be no less misleading, to call a scrum team or a few teams, working together on the same complex product, as “pool of resources”. A manager who says: “I got 15 resources on this project” – is a Taylorian Manager.
And back to the acronym of “HR”: by re-labeling “R” into Relationships makes the meaning of HR, as an abbreviation, so much stronger.
Indeed, how much more pleasant and comforting (psychologically, of course) would it be for an average worker to know that there is an organizational area (department)
that strongly fosters importance of human relationships inside an organisation?
Language and wording is powerful: it shapes behaviors.
For more references and publications about HR-related topics, please visit this page.
On 23-24th of February, there was the first ever 2017 – Business Agility Conference, held in NYC. The event could be best described as “…2 days of authentic short stories and facilitated deep dives on business agility; focus on organizational design, market disruption and product innovation, agile outside IT and next-generation leadership…” (quoted from https://businessagility2017.com/)
The uniqueness of this event was due its demographics, and in particular: due to the breakdown of attendees – based on their organizational roles. Although agile conferences (both, local and global) are never geared towards Technology and Information Systems only, this particular event was specifically geared towards business. As it can be seen from the statistics below, there were a very large number of people that represented Senior and Executive Management (more than 45%).
As always, another large share of attendees was represented by organizational and agile coaches.
It is also interesting to know that there were practically no discussions at the event about Scrum, Kanban, XP, tools, processes or frameworks, at the event.
My personal, experience as one of the facilitators of this event, was enriched by reuniting with some folks, whose work had significant impact on my own work:
|With Steve Denning||With Mike Beedle||With Bjarte Bogsnes|
Note: Special thanks to Mike Beedle for mentioning my name in his Enterprise Scrum Executive Summary. (download pdf report to view)
Highlights from Steve Denning’s Presentation:
According to Steve Denning – the author of Radical Management, 20th Century Teams – were “teams” in name-only. Team of the 20th century were gears of a classic, bureaucratic organizational machine, characterized by: top-down management, individual responsibilities and little interaction among people. On contrary, real Agile teams require: autonomy & cross-functional structure, collective accountability and high degree of interaction. Steve focused on the following four main Agile themes:
- Delighting Customer – there needs to be a fundamental shift in how management perceives relationships between Firm and Customer. This shift is best described by Copernican revolution: no longer Firm remains a centerpiece, with Customer revolving around it. Instead, Customer becomes a centerpiece and Firm revolves around Customer, delivering products, services and ensuring overall satisfaction. Pre- Copernican Management belief was in making the main purpose of a firm to generate money for its stakeholders and was best described by Jack Welch’s quote: “…The dumbest idea in the world…” The Post-Copernican Management belief is that, as was described by Peter Ducker in 1954: “…the only valid purpose of a firm is to create a customer…”
- Descaling Work – in a volatile and complex modern world, where uncertainty and ambiguity prevails, any attempts to resolve big problems simultaneously, with one big-bang approach, are no longer effective. Instead, work must be dis-aggregated in small batches and performed by small, autonomous, cross-functional teams.
- Enterprise-Wide Agility – to consider Agile as “IT thing only” is a huge mistake. Attempts to improve organizational agility, with only a few small teams trying to “do agile”, with the rest of the organization remaining top-down, bureaucratic, slow-moving behemoth will result in a failure. In order for the whole organization to become more agile, it has to embrace the entrepreneurial mindset front-to-back and top-to-bottom.
- Nurturing Culture – is a huge undertaking that each organization must commit to and flourish from within. This includes leadership strategies, organizational structure, culture, norms, values and principles. Excluding organizational design and system dynamics from agile transformation efforts by senior leaders is a costly mistake.
Throughout his presentation, Steve Denning highlighted additional important aspects of organizational agility:
- “How many layers should Organization have?” – There is no perfect number to give, but the fewer – the better. What matters is that there should be full transparency and direct communication between: Management, Customers/Users and Workers (employees, contractors, suppliers)
- The Law of Network – “plugging” agile team into a bureaucratic environment may create visibility of local efficiency but over time will lead to unbearable friction between “old” and “new”.
- There is a lot of “Agile PR” and “fake Agile” – it is usually brought about by IT attempts to embrace agility, with very limited support from business. Frequent claims from management (sometimes, very senior) that is indicative of their gross misunderstanding of organizational dynamics is:
- Agile is only for software
- Agile does not scale
- Agile cannot handle complexity
- Agile is not reliable
- Agile does not last
Steve Denning’s discussion was summarized by the example of Microsoft: “In 2004, Microsoft was viewed as a huge battleship, slowly moving through waters at relatively low speed, and not being able to turn quickly and cost-efficiently. In 2015, Microsoft is viewed as a flotilla of speedboats, moving fast but synchronously, and being able to turn “…on a dime for a dime…” (the author’s of this post quotes C. Larman)”
Highlights from Bjarte Bogsnes Presentation:
The chairman of Beyond Budgeting Roundtable (BBRT) Bjarte Bogsnes, who has a long international career in Finance and HR, with successful implementation of BB at two large European companies, Statoil and Borealis, presented a short synopsis on Adaptive Management Model.
(Note: Being Bjarte’s follower and advocate for years, I recommend for your attention the following personal summary page: for in-depth understanding of Bjarte’s work).
Bjarte made a clear distinction between Management and Leadership. People obey Managers (usually, mandatory) and follow Leaders (always, voluntarily). Management is focused on: Rhythms (around events), Targets, Plans and Forecasts, Resource Allocation, Performance Evaluation and Rewards Distribution. On contrary, Leadership is focused on: Purpose, Values, Transparency, Organization, Autonomy and Customers. A lot of focus in Bjarte’s discussion was paid to ineffectiveness of fixed (“accordion-like”) budgets that are driven by calendar years, not by business cycles; harm and dangers of producing and measuring wrong KPIs (often mistakenly considered as “KPTs”, where “T” stands for “truths”); lumping Budgets, Forecasts and Resources Allocation into one single KPI number, and then, coupling such ill-defined KPIs with individual appraisals and monetary rewards/bonuses – the main cause of system gaming and unethical behaviors that many organizations see today. Bjarte’s presentation was followed by comprehensive collaboration, by many individual teams that used a variety of visualization techniques to illustrate a future state of agile budgeting & finance:
Other Great Highlights:
There were a few other great discussions that took place at the conference. Here are a few excerpts that are worth including (paraphrased here):
- From Charlie Rudd: “…Organizational Change Management != Organizational Transformation. Many more people tend to resist to the former; much less so to the ladder…” and “…In Change Management, processes and system behaviors are predictable. In Transformations – they are not…”
- From Paul Cobban: “…Agile Education is not just for doers. It is also for Executive folks…Exempting themselves from continuous education, Executives lose touch with reality” and “…Stop Starting and Start Finishing…(or learn how to manage WIP at enterprise level)”
- From David Grabel: “…Agile is not just for IT. A great example of Agile adoption success is Marketing…” and “…Adoptive, agile Marketing can drive organizational agility at large…”
- From Venkateswaran NS: “…Do senior leaders have good vision? Does middle-management have right job descriptions (for themselves and their subordinates)?…”
- From Pat Reed: “…Business Agility – is bravery to step into the area of unknown…” and “…the phrase ”I will believe it when I see it”…should become “I will see it when I start believing it”
- From Fabiola Eyholzer: “…HR should stand for Human Relationships not Resources (from the author of this post: there is a common belief that calling humans as ‘resources’ is demotivating and disrespectful)…” and “…most discussions between employees and HR are scripted and lack sincerity and open-mindedness due to the fact that there is always a legal aspect to it and both parties are great of doing CYA…”
- From Chip Loving and Jason Hall: “…Management by Objectives is wasteful and harmful…” and “…Transparency != Awareness…(from the author of this post: being able to see something and fully comprehend it, is not the same thing)” and “…Quarter-based profit sharing that is peer-based and transparent is much better than end-of-year subjective discretionary bonus decided by people that are mostly remote from action and area, where real business value is produced…”
Finally, some great new publications were presented at the event. I came to discover that my colleague and friend, agile coach Dana Pylayeva has published her new book “Introduction to DevOps with Chocolate, LEGO and Scrum Game”. It goes on my To-Do list to read.
(The next Scrum @ Scale course taught by Jeff Sutherland is on March 2-3, in Boston, MA.)
More upcoming Agile Events in NYC:
- 02/23-24: Business Agility 2017 | NYC
- 04/28-30: Agile Coach Camp US| NYC
- 05/1: Big Apple Scrum Day 2017 | NYC
I continuously collect articles and publications that come from everywhere: colleagues coaches and trainers, clients, accidental encounters.
I keep a comprehensive list of resources here, categorized by themes.
Not all types of product development are the same. The most three distinct types are:
- Internal Product development, where
- Users/Customers are internal
- Product Owner is internal, playing the role of a conduit between Users and Technology
- Dev/Technology/IT is internal, mainly dealing with Product Owner (and her team)
- Outsourced Product (“Project”) development, where
- Users/Customers are internal
- Product Owner/Lead User is internal, playing the role of a conduit between internal Users and external Technology vendors
- Technology is external, represented by vendor-companies
- External Product Development, where
- Real (paying) Customers are external
- Product Owner (classic Product Management/Business Unit) is internal and facing external Customer
- Technology/R&D/Development is internal and interacts only with Product Owner
While these classifications may seem to be obvious, there are some important “nuances” that are often being overlooked. Awareness of these nuances could be important for making product development practices less vulnerable.
Here are some potential pitfalls to look out for, with each type of product development:
(Note: This post does not provide any recommendations on how to avoid/reduce pitfalls. Some suggestions might be covered in future publications.)
Internal Product development
- Fake Product Owners (delegates, proxies, surrogates) that lack either authority, or vision/breath of product knowledge, or both
- Artificial “internal contracts” between various company units, secondary to organization design. These, are often driven by internal competition, ineffective external motivation, subjective monetary incentives and bonuses
- Technology is too remote from real customers, does not deal with them directly and has to go through additional organizational layers, units, groups, roles (even to get to internal Product Owners)
- Excessive amount of processes, tools, metrics/KPIs and reports that are used as mechanisms for measuring business value delivered and levels of customer satisfaction. This is because of absence of real, short-loop customer feedback.
Outsourced Product (“Project”) development
- Low mutual trust (both, client and outsourcing company). Product development process is “wrapped” into artificial projects and portfolios, typically, with fixed scope, timeline and budget. Customer-vendor relationships are very contractual, with legal binders. While there are much more effective agile contracts that exist today, they are rarely used, because of lack of ability, by either side, to execute them.
- Documentation is voluminous and is at expense of collaboration and transparency. Approvals and sign offs are mandatory and are usually accompanied by rigid legal processes
- Unfit vendors: many companies still rely on vendors, with whom they have been dealing historically (via vendor management system), instead of turning to a market place, every time there is a new need, and searching for best candidates. Preferred vendors feel safe and comfortable, and with such “monopoly” in space, they have low, if any, desire to strive towards improving technical skills, adopting new technologies, etc. Also, nothing prevents such “preferred” vendors from making unsubstantiated claims about their experience with agile product development: rarely cases studies or references from other clients are requested. Fixed contracts just make things worse.
External Product Development
This product development type is probably the best candidate for agile approach: customers are real, real money exchanges hands, competition is real and often strong, fast market changes require product companies to be nimble, light-footed and fast-responding. However, there are still some challenges here.
Specifically, the communication channel called “Clarifications” (between Technology and external Customer) that is crucial in agile development (e.g. Scrum) is usually weak or does not exist at all. Due to geographic distribution, legal contracts and compliance issues, it is challenging to co-locate real customers and developers and have them directly engage with each other.
Since everything flows through Product Management /Marketing/Business internal organizational layer, technologists get their information second-hand. This also leads to producing additional overhead (processes, documentation, and approvals) by a product development company: multiple external communication channels and competing priorities (different customers) that must be collected/filtered/prioritized and then single-threaded to technology. To complete this job, internal Product Owner will require help. This is how internal Business Units grow thick and as this happens more waste/overhead is introduced to a system.
Kicking off 2017….
Non-IT Kanban Implementation at Scale