Agile Flyer – 11-24-2016

 

Key Steps To Success
Agile Flyer

Happy Thanksgiving!!! 

This week’s “Give Thanks For Scrum 2016” in Boston

On Tuesday November 22, Agile Boston celebrated its 8th Anniversary,
by organizing Annual Give Thanks For Scrum event.
The main theme of the event was: Scrum – A Foundational Element of Major Agile Scaling Frameworks.
During the event people learned from regional experts about how Scrum is at the heart of major Agile scaling frameworks like Scrum@Scale (from Scruminc.), Nexus (from Scrum.org),
SAFe and LeSS. Attendees also heard from regional executives who presented how successfully their organizations have scaled Scrum and the lessons they have learned along the way.

Event Speakers

Jeff Sutherland

 

David West

 

Gene Gendel

 

Daniel Mezick

 

Yuval Yeret

 

Tammy Sparrow

 

Rirchard Gratton

 

Patricia Taylor

 

speakers_group

Below are Top-5 take away points from each speaker:

 LeSS presentation, by Gene Gendel

  1. LeSS is NOT!: many teams doing their own Scrum OR “safe Heaven” for existing organizational dysfunctions OR an attempt to “scale” Scrum to match existing organizational complexity
  2. LeSS provides clear distinction between the two types of relationships that involve Scrum Team(s) and Business: Clarification (from users, customers, SMEs) and Prioritization (from Product Owner)
  3. Geographic distribution in Scrum that keeps team members together (even though it may separate individual teams that work on the same product) is still not as harmful as separating members of the same team
  4. Component Teams are caused by existing organizational silos and , subsequently, lead to Local Optimization (that merely offers Role Security), at expense of System Optimization
  5. Frequently made assumption that the role of conventional Project Manager and the role of Scrum Master are the same – is a mistake. These two roles are very different: they engage with teams completely differently and their behaviors are not the same. Project Manager – coordinates and takes full responsibility for deliverable. Scrum Master – facilitates, while the whole team is responsible for deliverable.

Scrum @ Scale, by Jeff Sutherland

  1. In 2016, lean alone is not sufficient enough. Agile competition goes way beyond lean manufacturing. It requires major changes in organization, management philosophy and operations.  Agile Transformations require Senior Leadership transform first.  Managers must become Leaders.
  2. Agile & Scrum can and should go much further than software development. They may touch all organizational domains
  3. Different companies have different needs for improved agility, e.g. Large Defense Contractor, mid-way software company, “Agile Native” company
  4. Strategic Objectives determine Agile Approach. But you have to descale organization first, in order to scale scrum
  5. FrAgile (“Shu” state) = CEO does not have agile mindset. Translation layer that sits between FrAgile layer and Waterfall layer (e.g. PMO), provides insulation and must be ultimately removed to get high performance

Nexus, by David West

  1. Scrum is the most popular way teams are approaching Agile – About 90% of Agile teams are using Scrum. Because of this it forms the basis of all the scaling approaches, even home grown (VersionOne survey 75% using a Scrum of Scrum approach to scale).
  2. Scaling where you add more systems, processes and organizational ‘stuff’ will not make you agile. Agility is the opposite with a strong focus on empowered teams working in a environment that support the three pillars of inspection, adaption via transparency.
  3. Nexus is a light weight exoskeleton for Scrum helping teams have a consistent approach to scaling their product development. Nexus is not an approach to Agile IT, instead focusing on how you can have 3-9 teams working together on a backlog with a large number of dependencies.
  4. Nexus is still Scrum, but adding an additional role of Nexus Integration Team, events of Nexus Sprint planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective, and Refine, and Artifacts of the Nexus Sprint Backlog and Nexus Goal.
  5. If you have bad Scrum, Nexus will just highlight the bad – good Scrum makes scaling work.

SAFe, by Yuval Yeret and Daniel Mezick

  1. We need to scale Scrum DNA, not just Scrum practices
  2. “You can have things your way and push it if want, but this door is pretty stubborn”. – “PUSH” approach does not work well with systems. You have a better chance to succeed if you “PULL”
  3. What do you get when you scale an Agile Theater (a.k.a. Waterfall)? You get SAFe Theater (Starring the Managers-Only PI Planning, The Command & Control RTE, w/ special guest – Waterfall Thinking)
  4. Scrum is a foundational piece of SAFe’s Team Level and is best seen on Essential SAFe 4.0 schema
  5. In order to SAFely scale agile, you must use Real/Genuine Scrum DNA + Lean/Agile Principles + Leadership

 

…Something else you need to know about LeSS….

 

Scrum Alliance (SA), by far, is the largest agile organization, worldwide, and is represented by so many highly exprienced Coaches and Trainers, whose main goal is best described by the following slogan: “we are changing the world of work“.  While educational curriculum, delivered by SA Certified Scrum Trainers (CSTs) is very rich, its main focus has mostly been on Agile Manifesto (with its values & principles), core Scrum (with its roles, responsibilities, artifacts and ceremonies), and with orientation towards and support of basic Scrum certifications, such as CSM, CSPO and CSD.Scrum Alliance has never taken an official position with regards to agile/scrum adoptions at scale.
Its position has always been neutral and agnostic to scaling: “our Coaches and Trainers are versatile enough to pick the best approach for their clients”.
And indeed, when it comes to recommending scaling solutions, Certified Enterprise Coaches (CECs) and Certified Scrum Trainers (CSTs)
have a plenty of ‘scaling tools’ in their toolbox to offer, and they do it situationally, based on specific needs of each client.However, over the last few years, there has been a very strong trend in CST/CEC community with regards to scaling preferences.
If we take into account shared personal experience, case studies and research, coming from Coaches and Trainers, it becomes apparent that a very significant number of them are very supportive of Large Scale Scrum (LeSS), as a preferred scaling approach. Many CSTs have built LeSS teaching in their CSM and CSPO courses. Many CECs have been using LeSS, with its strong principles, guidelines and numerous expericences to de-scale companies, challenge classic system dysfunctions and improve organizational design.Many CECs and CSTs have also become Certified LeSS Parctititioners (CLP) by attending LeSS courses. Also, there is a growing number of
CECs and CSTs that are in pursuit of LeSS Trainer accreditation – to be able to teach LeSS in a more structured way.What does this overwhelming interest in LeSS mean for the agile community at large? For organizations? For Coaches, Trainers, Scrummasters,
Product Owners, teams?

Will LeSS become the “main stream” for scaling in a future?
Will it become as widely recognized in the US as it is in Europe and EMEA (another very interesting trend that is observed!!!)?
It is worth mentioning that there are a few other good agile scaling frameworks available. But LeSS seems to be picking picking up speed and noticeably.
Time will show…Perhaps, soon…

With that said, here is the great opportunity to learn Large Scale Scrum from Craig Larman himself — he is the co-creator of LeSS.

This is the last opportunity this year and probably for a while now (Craig is planning to engage long-term with one of his clients) –
to have LeSS course taught by Craig himself, in its very original form.

Also, receiving LeSS training directly from Craig has another great benefit:
Craig has probably the most exentsive list of experiments with LeSS adoptions and has many real life stories to tell.

 

About the course:

 In this 3-day highly-participative course, people will get a thorough understanding of Large Scale Scrum,
for scaling agile development to many teams working together on one product.

In-depth, you will explore adoption, new organizational design, systems thinking & optimization, the role of management, and approaches of working together in Sprints at scale, by optimizing coordination, architecture and planning.

This course will also include an in-depth Q&A clinic based on Craig’s long experience with LeSS adoptions.

Here are some highlights of the course:

  • LeSS Overview (LeSS principles, frameworks, guides, experiments)
  • Two LeSS frameworks: basic & LeSS Huge
  • Adoption (pre-adoption & the adoption guides, 3 principles, getting started, scope of first adoption, stories of LeSS adoptions
  • Local Optimization & System Optimization
  • Adoption: Organizing by Customer Value
  • Shu-Ha-Ri and frameworks
  • Empirical process control
  • Occupational psychology
  • Lean thinking & value-driven
  • LeSS Sprint
  • Done & Undone in LeSS
  • LeSS Rules
  • LeSS Huge Framework
  • More on LeSS Roles
  • Managers in a LeSS organization
  • ScrumMasters at scale
  • Product Owner in LeSS
  • In-Depth Special Topics: A Deep-Dive Q&A Clinic
  • ….and much more…

If yo would lile to read more about the agenda of this course and register, please follow this link.  You may use the following discount code: hrte416 get a cheaper price.

“Give Thanks For Scrum 2016” in Boston

On Tuesday November 22, 2016 Agile Boston celebrated its 8th Anniversary, by organizing Annual Give Thanks For Scrum event. The main theme of the event was: Scrum – A Foundational Element of Major Agile Scaling Frameworks.
During the event people learned from regional experts about how Scrum is at the heart of major Agile scaling frameworks like Scrum @ Scale (from Scruminc.), Nexus (from Scrum.org), SAFe and LeSS. Attendees also heard from regional executives who presented how successfully their organizations have scaled Scrum and the lessons they have learned along the way.

Event Speakers


Jeff Sutherland

David West

Gene Gendel

Daniel Mezick

Yuval Yeret

Tammy Sparrow

Rirchard Gratton

Patricia Taylor

speakers_group

Below are Top-5 take away points from each speaker:

LeSS presentation, by Gene Gendel

006

  1. LeSS is NOT!: many teams doing their own Scrum OR “safe Heaven” for existing organizational dysfunctions OR and attempt to “scale” Scrum to match existing organizational complexity
  2. LeSS provides clear distinction between the two types of relationships that involve Scrum Team(s) and Business: Clarification (from users, customers, SMEs) vs. Prioritization (from Product Owner)
  3. Geographic distribution in Scrum that keeps team members together (even though it may separate individual teams that work on the same product) is still not as harmful as separating members of the same team
  4. Component Teams are caused by existing organizational silos and , subsequently, lead to Local Optimization (that merely offers Role Security to certain people), at expense of System Optimization
  5. Frequently made assumption that the role of conventional Project Manager and the role of Scrum Master are the same – is a mistake. These two roles are very different: they engage with teams completely differently and their behaviors are not the same. Project Manager – coordinates and takes full responsibility for deliverable. Scrum Master – facilitates, while the whole team is responsible for deliverable.

Scrum @ Scale, by Jeff Sutherland

008

  1. In 2016, lean alone is not sufficient enough. Agile competition goes way beyond lean manufacturing. It requires major changes in organization, management philosophy and operations. Agile Transformations require Senior Leadership transform first. Managers must become Leaders.
  2. Agile & Scrum can and should go much further than software development. They may touch all organizational domains
  3. Different companies have different needs for improved agility, e.g. Large Defense Contractor, mid-way software company, “Agile Native” company
  4. Strategic Objectives determine Agile Approach. But you have to descale organization first, in order to scale scrum
  5. FrAgile (“Shu” state) = CEO does not have agile mindset. Translation layer that sits between FrAgile layer and Waterfall layer (e.g. PMO), provides insulation and must be ultimately removed to get high performance

Nexus, by David West

009

Scrum is the most popular way teams are approaching Agile – About 90% of Agile teams are using Scrum. Because of this it forms the basis of all the scaling approaches, even home grown (VersionOne survey 75% using a Scrum of Scrum approach to scale).

  1. Scaling where you add more systems, processes and organizational ‘stuff’ will not make you agile. Agility is the opposite with a strong focus on empowered teams working in a environment that support the three pillars of inspection, adaption via transparency.
  2. Nexus is a light weight exoskeleton for Scrum helping teams have a consistent approach to scaling their product development. Nexus is not an approach to Agile IT, instead focusing on how you can have 3-9 teams working together on a backlog with a large number of dependencies.
  3. Nexus is still Scrum, but adding an additional role of Nexus Integration Team, events of Nexus Sprint planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective, and Refine, and Artifacts of the Nexus Sprint Backlog and Nexus Goal.
  4. If you have bad Scrum, Nexus will just highlight the bad – good Scrum makes scaling work.

SAFe, by Yuval Yeret and Daniel Mezick

007

  1. We need to scale Scrum DNA, not just Scrum practices
  2. “You can have things your way and push it if want, but this door is pretty stubborn”. – “PUSH” approach does not work well with systems. You have a better chance to succeed if you “PULL”
  3. What do you get when you scale an Agile Theater (a.k.a. Waterfall)? You get SAFe Theater (Starring the Managers-Only PI Planning, The Command & Control RTE, w/ special guest – Waterfall Thinking)
  4. Scrum is a foundational piece of SAFe’s Team Level and is best seen on Essential SAFe 4.0 schema
  5. In order to SAFely scale agile, you must use Real/Genuine Scrum DNA + Lean/Agile Principles + Leadership

Another Kodak moment with Jeff Sutherland

jeff_gene

 

Agile Flyer – 11-14-2016

Key Steps To Success

Agile Flyer

Please, scroll to bottom for key upcoming events.

How to Cultivate T-Shaped Developers?

Scrum Team.  It is a cross-functional group of developers that are able to deliver complete business functionality (“from concept to cash”) to customers in a short time-frame.  The easiest way to make sure that a team is cross-functional is to compose it of developers that are initially multi-skilled and possess both, primary and secondary skills.  Such people are usually referred to as T-shaped, where “…the vertical bar on the T represents the depth of related skills and expertise in a single field, and the horizontal bar is the ability to collaborate across disciplines with experts in other areas…”[wikipedia].

There is a common mis-belief that T-shaped individuals are hard to find. Here, are some of the most frequently heard concerns that we hear from hiring managers and HR:

  • “Most people we come across do not have enough technical diversity”
  • “It is hard to find individuals with certain skill set in a particular geographic area. Best folks with a required skill set can be found only in a particular area”
  • “We are having difficult time encouraging our team members to learn secondary technologies on the job”

Below are some suggestions for how to acquire or internally cultivate and retain good, multi-skilled, T-shaped developers:

Frame job requirements clearly:

Companies have to ensure that their job requirements, clearly state that they are looking for multi-skilled workers. Jobs must be titled accurately, including the mentioning that people are expected to work on Scrum teams, wear multiple hats, contribute to learning of other their teammates and actively learn themselves. Still, very commonly, we see job descriptions that are titled in favor of conventional single-specialty roles (e.g. BA, Java back-end Developer, QA or Architect). While commonly used buzz words, like ‘agile’ and ‘scrum’ are still mentioned in job requirements, proper meaning of these words is not communicated well enough and sometimes is simply misstated. Also, the importance of having multiple skills is reduced by emphasizing titles of conventional, single-specialty roles. Therefore, it is not surprising that people that get attracted to such job requirements, rely merely on their original, single skill set, and don’t have much appetite for extended learning and becoming T-shaped.

Assess candidates properly, before hiring, and ask for things that really matter:

Today, in a typical hiring process, many companies still make too much emphasis on things that matter little. Mainly, due to outdated HR procurement methods and hiring policies, but also, to some extent, because companies rely on inadequately trained recruiting staff (sometimes, external), job candidates get “screened” for wrong things, and under wrong conditions. Some pre-qualifying, “templated” questions (e.g. “are you able to to work under stress?”, “are you an outstanding performer?”, “can you be a great team player?”, “can you describe a difficult situation and solution that you came up with?”, etc.) have little to do with real job requirements and should be treated as ‘common sense’.

The biggest downside of using such low value qualifiers in screening is that they cost time and shift focus of both, interviewers and candidates, away from things that really matter. Also, such phone screening by a single person (e.g. HR or hiring manager) are more prone to bias, and misinterpretation. Phone screening could still serve some purpose if it scope is reduced to something basic, and much less time consuming. For example, determination of a candidate’s legal status and work permission to work or scheduling an in-person interview.

Note: discussing compensation ranges is not advisable by phone, as some strongly qualified candidates, with slightly out-of-range salary expectations, may get disqualified by screening people that don’t have the best understanding of a relationship between “service value and cost of service” and do know know where compensation range should be tweaked for a right candidate.

It is more advisable to reduce time spent on phone screening, in favor in-person interviews with inclusion of practical assessment of individuals’ technical knowledge, their cross-functional capability, and ability to operate in Scrum team settings. To that end, it makes more sense, to involve an entire Scrum team (future team where a candidate will work for) in multiple steps of an interviewing process, including assessment of social, soft and technical skills, while using simulation techniques that mimic a team’s daily dynamics.

Pay developers well:

  • “Good, cross-functional developers are hard to find”
  • “There are no experienced Java coders in Chennai”
  • “The best architects on East Coast of the US are in Boston”

We hear these arguments a lot.

Truth be told, good developers can be found almost anywhere; companies just need to figure out better ways of attracting them. This includes, and often comes down to, paying people fairly and competitively.

No single geographical place in the world miraculously grows “the best” technologists of a one particular kind. Certainly, some trends exist, perhaps, where workers relocate, as they follow large companies that offer jobs. But often statistics that describe these trends taken out of proportion, data is misinterpreted and numbers are exaggerated. Ability to find best developers of one particular type, in one geographic area, most likely, hints to another, more likely theory: companies that claim the above “phenomena” are themselves responsible for creating conditions for such disparity in the first place.

Often, in pursuit of cheaper labor, companies consolidate all their developers of more expensive skill set (e.g. Java developer is more expensive than HTML developer) in the cheapest geographic location. What companies don’t realize is that this decision creates the following challenges for Scrum:

  • Firstly, this goes against key principles of team collocation that are critical in Scrum: consolidation of all developers of the same skill set in one geographic location, makes it hard to co-locate cross-functional teams. Effectively, with this approach, companies create collocated component teams, at expense of co-located feature (a.k.a. scrum) teams – but it is the latter that is best for agile product development.
  • Secondly, being collocated with people of the same exact skill set makes it hard for individuals to learn new skills from one another (condition of technological “in-breeding”).

Ensure that work environment and team dynamics support knowledge sharing between developers:

One of the most critical requirements that ensure that individuals are willing to share knowledge with their teammates while working, is the existence of safe collaborative environment, free of internal competition. Willingness to cross-pollinate with skill set (and become T-shaped) is much higher on teams and in organizations, where people perceive each other as mutually supportive peers, not as rivals. This can be achieved by strongly supporting ideas of collective ownership and shared responsibility, by emphasizing the importance of team performance, while discouraging individual heroics, knowledge withholding and silos. Organizational cultures, where individual performance is overly empathized and individual performance appraisals drive bonuses and monetary insensitive, employees’ willingness to share knowledge, teach each other and contribute to mutual T-shaping, while delivering work together, is significantly reduced. Many other undesirable behaviors (e.g. hostility, favoritism, etc) are frequently seen as well.

This fundamental improvement in working conditions requires strong commitment and support of senior leadership.

Provide internal career path for hands-on developers, to ensure long-term engagement:

Today, a typical career path for a successful technologist requires to sacrifice hands-on work, in favor of managing other people. Developers think that by becoming a manager and getting in charge of more junior workers, will increase their own chance to be promoted, move up a hierarchical ladder and collect more pay. This is commonly seen in companies with very complex organizational structures and command & control environments but less so, in companies with less hierarchical, flattened structures. This anxious pursuit to become a “manager-in-control”, reduces a number of good developers that can deliver value, by performing hands-on work. People are reluctant to remain in the role of a developer for too long because it is perceived as stagnation of professional growth. Also, people feel that it is more difficult to get a decent pay increase by simply remaining in the capacity of a “worker bee”. Many good developers with already strong primary skill set are reluctant to acquire additional technical skills, because they view this approach as a “low return on investment”, comparatively, to pursuing a management role. To them, becoming a manger is a more certain way to grow in ranks and in compensation.

What can companies do to address individuals’ reluctance of remaining in a role of a hands-on developer?

Arguably, companies have to decouple the process of promotion (gaining seniority, reputation, organizational weight) and compensation increase from acquisition of “power tower” control. Individual workers must have assurance that by keeping their hands on-technology, deepening their primary technical skills and broadening secondary skills, they will not be missing out on career advancement and ability to make a better living. People must also be assured that by becoming higher compensated, over time, while still remaining in a capacity of “hands-on doers”, they will not be becoming an easy target for downsize/force reduction, in favor of younger and “cheaper” work force that will come from colleges and universities. Here, a strong bet is being made on the assumption that senior hands-on workers, with longer industry experience, will have much more technical expertise that is coupled to business domain knowledge – something that shall make their higher pay well justified by employers.

Again, this organizational change is dependent on decisions that come from senior echelons of organizational structures.

If you would like to see this post on-line, please click here

Upcoming Agile Events in NYC:
Fresh Collection of Ad-hoc Agile References:

 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.

How to Cultivate T-Shaped Developers?

Scrum Team.  It is a cross-functional group of developers that are able to deliver complete business functionality (“from concept to cash”) to customers in a short time-frame.  The easiest way to make sure that a team is cross-functional is to compose it of developers that are initially multi-skilled and possess both, primary and secondary skills.  Such people are usually referred to as T-shaped, where “…the vertical bar on the T represents the depth of related skills and expertise in a single field, and the horizontal bar is the ability to collaborate across disciplines with experts in other areas…”[wikipedia].

There is a common miss-belief that T-shaped individuals are hard to find.  Here, are some of the most frequently heard concerns that we hear from hiring managers and HR:

  • “Most people we come across do not have enough technical diversity”
  • “It is hard to find individuals with certain skill set in a particular geographic area. Best folks with a required skill set can be found only in a particular area”
  • “We are having difficult time encouraging our team members to learn secondary technologies on the job”

Below are some suggestions for how to acquire or internally cultivate and retain good, multi-skilled, T-shaped developers:

Frame job requirements clearly:

Companies must ensure that their job requirements, clearly state that they are looking for multi-skilled workers.  Jobs must be titled accurately, including the mentioning that people are expected to work on Scrum teams, wear multiple hats, contribute to learning of other their teammates and actively learn themselves.  Still, very commonly, we see job descriptions that are titled in favor of conventional single-specialty roles (e.g. BA, Java back-end Developer, QA or Architect).  While commonly used buzz words, like ‘agile’ and ‘scrum’ are still mentioned in job requirements, proper meaning of these words is not communicated well enough and sometimes is simply misstated.  Also, the importance of having multiple skills is reduced by emphasizing titles of conventional, single-specialty roles.  Therefore, it is not surprising that people that get attracted to such job requirements, rely merely on their original, single skill set, and don’t have much appetite for extended learning and becoming T-shaped.

Assess candidates properly, before hiring, and ask for things that really matter:

Today, in a typical hiring process, many companies still make too much emphasis on things that matter little.  Mainly, due to outdated HR procurement methods and hiring policies, but also, to some extent, because companies rely on inadequately trained recruiting staff (sometimes, external), job candidates get “screened” for wrong things, and under wrong conditions.  Some pre-qualifying, “templated” questions (e.g. “are you able to to work under stress?”, “are you an outstanding performer?”, “can you be a great team player?”, “can you describe a difficult situation and solution that you came up with?”, etc.) have little to do with real job requirements and should be treated as ‘common sense’.

The biggest downside of using such low value qualifiers in screening is that they cost time and shift focus of both, interviewers and candidates, away from things that really matter.  Also, such phone screening by a single person (e.g. HR or hiring manager) are more prone to bias, and misinterpretation.  Phone screening could still serve some purpose if it scope is reduced to something basic, and much less time consuming. For example, determination of a candidate’s legal status and work permission to work or scheduling an in-person interview.

Note: discussing compensation ranges is not advisable by phone, as some strongly qualified candidates, with slightly out-of-range salary expectations, may get disqualified by screening people that don’t have the best understanding of a relationship between “service value and cost of service” and do know know where compensation range should be tweaked for a right candidate.

It is more advisable to reduce time spent on phone screening, in favor in-person interviews with inclusion of practical assessment of individuals’ technical knowledge, their cross-functional capability, and ability to operate in Scrum team settings.  To that end, it makes more sense, to involve an entire Scrum team (future team where a candidate will work for) in multiple steps of an interviewing process, including assessment of social, soft and technical skills, while using simulation techniques that mimic a team’s daily dynamics.

Pay developers well:
  • “Good, cross-functional developers are hard to find”
  • “There are no experienced Java coders in Chennai”
  • “The best architects on East Coast of the US are in Boston”

We hear these arguments a lot.

Truth be told, good developers can be found almost anywhere; companies just need to figure out better ways of attracting them. This includes, and often comes down to, paying people fairly and competitively.

No single geographical place in the world miraculously grows “the best” technologists of a one kind.  Certainly, some trends exist, perhaps, where workers relocate, as they follow large companies that offer jobs. But often statistics that describe these trends taken out of proportion, data is misinterpreted and numbers are exaggerated.  Ability to find best developers of one type, in one geographic area, most likely, hints to another, more likely theory: companies that claim the above “phenomena” are themselves responsible for creating conditions for such disparity in the first place.

Often, in pursuit of cheaper labor, companies consolidate all their developers of more expensive skill set (e.g. Java developer is more expensive than HTML developer) in the cheapest geographic location.  What companies don’t realize is that this decision creates the following challenges for Scrum:

  • Firstly, this goes against key principles of team collocation that are critical in Scrum: consolidation of all developers of the same skill set in one geographic location, makes it hard to co-locate cross-functional teams. Effectively, with this approach, companies create collocated component teams, at expense of co-located feature (a.k.a. scrum) teams – but it is the latter that is best for agile product development.
  • Secondly, being collocated with people of the same exact skill set makes it hard for individuals to learn new skills from one another (condition of technological “in-breeding”).
Ensure that work environment and team dynamics support knowledge sharing between developers:

One of the most critical requirements that ensure that individuals are willing to share knowledge with their teammates while working, is the existence of safe collaborative environment, free of internal competition.  Willingness to cross-pollinate with skill set (and become T-shaped) is much higher on teams and in organizations, where people perceive each other as mutually supportive peers, not as rivals.  This can be achieved by strongly supporting ideas of collective ownership and shared responsibility, by emphasizing  the importance of team performance, while discouraging individual heroics, knowledge withholding and silos.   Organizational cultures, where individual performance is overly empathized and individual performance appraisals drive bonuses and monetary insensitive, employees’ willingness to share knowledge, teach each other and contribute to mutual T-shaping, while delivering work together, is significantly reduced.  Many other undesirable behaviors (e.g. hostility, favoritism, etc) are frequently seen as well.

This fundamental improvement in working conditions requires strong commitment and support of senior leadership.

Provide internal career path for hands-on developers, to ensure long-term engagement:

Today, a typical career path for a successful technologist requires to sacrifice hands-on work, in favor of managing other people.   Developers think that by becoming a manager and getting in charge of more junior workers, will increase their own chance to be promoted, move up a hierarchical ladder and collect more pay.  This is commonly seen in companies with very complex organizational structures and command & control environments but less so, in companies with less hierarchical, flattened structures. This anxious pursuit to become a “manager-in-control”, reduces a number of good developers that can deliver value, by performing hands-on work.  People are reluctant to remain in the role of a developer for too long because it is perceived as stagnation of professional growth.  Also, people feel that it is more difficult to get a decent pay increase by simply remaining in the capacity of a “worker bee”.  Many good developers with already strong primary skill set are reluctant to acquire additional technical skills, because they view this approach as a “low return on investment”, comparatively, to pursuing a management role. To them, becoming a manger is a more certain way to grow in ranks and in compensation.

What can companies do to address individuals’ reluctance of remaining in a role of a hands-on developer?

Arguably, companies have to decouple the process of promotion (gaining seniority, reputation, organizational weight) and compensation increase from acquisition of “power tower” control.  Individual workers must have assurance that by keeping their hands on-technology, deepening their primary technical skills and broadening secondary skills, they will not be missing out on career advancement and ability to make a better living.  People must also be assured that by becoming higher compensated, over time, while still remaining in a capacity of “hands-on doers”, they will not be becoming an easy target for downsize/force reduction, in favor of younger and “cheaper” work force that will come from colleges and universities.  Here, a strong bet is being made on the assumption that senior hands-on workers, with longer industry experience, will have much more technical expertise that is coupled to business domain knowledge – something that shall make their higher pay well justified by employers.

Again, this organizational change is dependent on decisions that come from senior echelons of organizational structures.

 

November 3 – Mike Beedle on Enterprise Scrum

This was a blasting event, with one of the co-signers of Agile Manifesto: Mike Beedle, being our honorable guest.

Mike’s presentation (outlined below) was followed by comprehensive Q&A.  Some folks were wise enough to have Mike hand-sign Agile Manifesto copy 🙂

Summary of Mike’s talk:
  • Enterprise Scrum (ES) goes much further than Technology alone.  ES grows Unicorns and transforms Dinosaurs.  ES is:
    • Balanced Management
    • Integrated Agility
    • Principles & Techniques
    • Management Framework
  • ES mandates Management of new breed.  Today, most of Management taught at colleges and universities is completely outdated.
  • In 10 years from now, “S&P 500 Membership” will be different than it is today. And companies that don’t become more agile will know it first
  • Conventional performance management is an outdated process that must be redefined
  • The most effective way to ensure a successful agile transformation (especially, at a large organization) is to “spin off” a small internal entity that would be free of certain existing counter-agile organizational laws, mandates, norm and behaviors.  Such organisation should be ‘real’, having its “front-” and “back-end”
  • Financial firms that don’t  also think of themselves as technology firms (worse yet, outsource their technical solutions elsewhere) will have difficult times in years to come
Some Kodak moments below:

meetup_mike_beedle-7

meetup_mike_beedle-6

meetup_mike_beedle-12

meetup_mike_beedle-11meetup_mike_beedle-3 meetup_mike_beedle-4

meetup_mike_beedle-10

meetup_mike_beedle-9

meetup_mike_beedle-14