Category Archives: Event

December 6th-8th: Certified LeSS Practitioner Course With Craig Larman | NYC


Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.

More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.

Course Highlights

With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum.  It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework.  On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.

Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner?   Well…

  • LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner.  LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block.  Understanding basic Scrum made understanding of LeSS very easy for everyone.
  • The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in.  Everyone in class was an educated customer.  Importantly: there were no attempts to change LeSS (or change training content 😊  of LeSS), to make it better fit conditions of organizations, where people came from.
  • Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.

The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)

One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many).  And it goes as follows:

…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle).  ‘Agile’ won because of the reasons that are described here.  Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible.  We all have to be careful with the meaning of words we use, to avoid this painful irony😉.


Here are some Kodak moments from the event:

NYC Salary History Ban – What Does it Mean?


On October 31-st, 2017, the Mayor of NYC Bill de Blasio signed the new Law, prohibiting companies in New York City from asking, searching or verifying a job applicant’s salary history during the hiring process.  From now on, violation of this law, by any NYC-based employer, will be viewed as an “unlawful discriminatory practice.”
(Please, read more about the NYC Salary History Ban.)

Below are some potential, consequences of this Law, as it applies to any employees-candidates and any NYC-based employing organizations:

  • If an individual has worked for a long time at the same company and, while employed, has acquired a lot of practical experience/skill set, but unfortunately was not able to secure compensation that was an objective reflection of her capabilities/expertise, she may now seek an employment at another company without worrying that prior, unfairly low compensation, will be a benchmark for her future offer.
  • If an individual is a self-starter/entrepreneur who has acquired a lot of knowledge/experience in ways, other than formal employment (e.g. self-paid study or research) and by doing so, has significantly increased her professional maturity, she may confidently leverage these rightfully owned credentials , when negotiating a salary with her next employer.
  • If an individual’s goal has always been to remain as a hands-on contributor (she loved what she did, and did not want to lose her practical skills) and was never aspired to seek a promotional/managerial position – something that usually leads to higher compensation, she may do so more freely, without worrying that she will miss out on a “compensation-bargaining-chip”, at her next job interview.  This also means that employees will be more experience/knowledge-seeking and less promotion-seeking, as it is really an experience, not prior organizational position that define their true self-selling power.  (note: often, promotions are associated with loss of hands-on expertise, in favor of managerial/administrative responsibilities).
  • If an individual’s full compensation consists of base salary and discretionary bonus (the latter, often being too subjective, as it is based on individual performance appraisals, efficiency of which have been proven as ineffective, for many decades), with a bonus, representing a significant chunk of her full salary, she does not have to be concerned so much with her next employer, trying to count in only her base salary,  as a ‘benchmark’ , while making an offer.  This will also, hopefully, drive companies towards paying higher base salaries, and away from subjective bonuses.
  • Recruiting agencies and staffing firms will have fewer opportunities to ask unethical questions (“how much were/are you making at your prior/current job?”), something that is often delegated to them by companies’ HR departments, with the ladder not wanting to be directly associated with unethical behaviors.  Further, this may lead to more transparency and direct interaction between hiring managers and candidates.
  • Companies-employers would have to improve their vetting/interviewing/hiring approaches significantly, by incorporating validation methods and more reliable/objective assessments of candidates, to prevent under-qualified, low-skilled individuals (some of whom may have strong negotiations and “talking the talk” skills) from slipping through companies’ doors and causing internal problems.  This may require conducting more practical tests, real-life simulations and hands-on exercises, administered directly by hiring areas and peers-coworkers. Further, this could also reduce an amount of subjective/administrative, error-prone and often unnecessary screening processes, usually handled by companies’ departments that are least benefited from hiring high-quality candidates, but at the same time, most benefited from creating and administering actual processes 🙂

In all the above situations, the main compensation-determining factors will be:

  • From an employee’s perspective: her professional competency, skill/mind set, ability to produce tangible results and deliver business value
  • From an employer’s perspective: ability to properly assess a candidate for what she is worth (not for what she was price-tagged in her past) AND clear understanding of how much an employer is willing to pay for a given job/to a given candidate

The natural question that comes to mind:  Does the new Law have any relevance to internal hiring situations (when employees move around a company)?  

According to the Employer Fact Sheet, the Law does not apply directly to internal re-employment (also, for most companies, employees’ compensation is transparent to hiring managers of the same company).

However….  There could be some indirect implication: NYC-based employers will probably realize that properly educated (know the Law) employees will have more confidence to ask a higher pay, when they seek a new employment internally.  The new “compensation-bargaining chip” for employees will be their increased self-confidence that they will be able to get a higher compensation elsewhere, irrespective of their current compensation (should their internal efforts not materialize).  As a result, to avoid losing good people to their direct competitors, employers will probably revisit their compensation increase standards, with regards to internal  re-employments.

10/13 – LESS TALKS: MEETUP – Working LeSS Brings Great Results (Case Study)


Tonight -a  great presentation by Malik Graves-Pryor of Natoma Consulting, as he shared how his company leveraged LeSS to achieve  stunning results, while facing challenges and learning lessons.

Malik’s Summary

At the Thursday October 12, 2017 NYC Large Scale Scrum Meetup, Malik Graves-Pryor shared his company’s LeSS case study, “Web and Mobile Applications Agile Transformation”. He covered the extensive issues the company faced at the beginning ranging from only 1-2 releases a year with hundreds of defects, and how they transformed over the course of several months to an organization that released monthly, and then continuously, with low defects and high customer satisfaction and engagement.

The discussion covered the merger of the Sales and Product Management Pipelines, adoption of technical practices leading to a DevOps-focused culture, how to take the necessary steps to build trust and cooperation within the organization, as well as the road-map they used to iteratively migrate the organization to continuous integration and deployment.

The interactive discussion spanned two hours with attendees raising questions and issues about the case study, as well as correlating them with their own challenges and aspirations.

Presentation deck is available at  Natoma Consulting website for download.

 

How Detailed Should Business Requirements Be? Discovery Through Agile Gaming.


Last week, at New York Scrum User Group (NYSUG) monthly event, co-facilitated by  the agile coaches Dana Pylayeva and Emilie Franchomme, there were multiple agile games presented – all for different purposes and for all types of audience.  Above all, what really stood out was  the “Beautiful Meadow” game that helped with making a revealing discovery about handling business requirements.  Below is the summary:

Game Rules:

Team A and Team B, of 8 people each,  were given the following drawing instructions (click on the image below to enlarge):

Team A Team B

The requirements of Team A were very detailed, whereas the requirements of Team B were rather generic.   Each team was given a set of color markers and a  large flip-chart sheet.  Both teams were allowed to review the requirements in silence – for 30 seconds.  Then both teams were given another 60 seconds to draw a picture, based on given requirements, but they were allowed to collaborate in sign language only.

Observations and Results:

For the first 30 seconds of the exercise both teams’ dynamics were very similar: hurdling around the requirement, trying to understand it, orienting yourselves are around the canvas.   Silently,  some people seemed to volunteer to draw various elements of the picture.  For the second 60 seconds interval, dynamics significantly changed:

At a glace, Team A seemed to be somewhere less organized and more hectic.  People seemed to move around the canvas anxiously, trying to pull markers from each other’s hand.  What also became obvious was that each person was trying maximize their contribution to the picture, by drawing in a silo, without much collaboration with others.

Team B, on the other hand, seemed to be much more organized and focused.  Individual work of each person seemed like a continuity of someone else’s effort.  Markers were effectively passed on from one person to another.  There was much more collaboration and common effort here.

After 60 seconds of drawing, the teams produced two images, illustrated below: Team A  – left canvas, Team B -right canvas (click on the image below to enlarge):

Team A has produced a picture that consisted of multiple disjointed elements that together did not seem to fit well.   Oddly it even produced two suns – in two opposite corners of the canvas, whereas the instructions  clearly asked only for one sun.

On contrary, Team B was able to produce a simple, coherent logical picture, with each element enriching the overall composition with  additional relevant detail.

Conclusion:

This exercise clearly demonstrated that too detailed requirements, passed on to a group of individuals, as one conclusive document, are executed much poorer than light requirements  passed on to a similar group of people.  In case of Team B, there was a request of “WHAT” to draw, not “HOW”.  The team was able to use all of this innovation and artistic skills to produce what was required.   Oppositely, team A was asked to delivery “WHAT & HOW” and the teams’ ability improvise on-the-fly was significantly reduced.

Disclaimer:

There were two sets of teams (two Team A and two Team B) and the results produced by the second set of teams were very similar to the case described above.

Relevant Article: Waterfall Requirements in Agile Product Development

You Get What you Ask For: Agile Coaches-“Centaurs”


Why are there so many troubled agile “transformations”?  We frequently hear the following answer: “because companies lack senior leadership support”.  True.  And let’s not trivialize this: without strong and genuine support by senior leadership (beyond slogans and “support in spirit”), without selecting a deep, systemic approach to problem resolution, companies can only expect localized, peripheral and, most likely, short-term improvements.

But is there anything/anyone else that can be conveniently held accountable for failed agile transformations?

How about ineffective agile training and coaching?  [Note: If you are interested in learning more about some of the most common challenges with agile training, please visit this page.  This post is about coaching .]

…There is a vicious cycle that hurts so many companies (can be also considered as a self-inflicted wound):

initially, companies set a low bar for coaches, based on poor understanding of a coaching role  low quality coaches (quasi-coaches-“centaurs”) are hired, most of whom are not even coaches, but rather people that have mastered agile jargon and know how to impress HR and uninformed hiring managers  weak coaches (most of whom have minds of conformists, not challengers) cannot effectively guide companies to fix systemic weaknesses and dysfunctions  teams and departments  don’t really improve; rather create a superficial appearance/illusion of progress (often, to impress senior management)  companies lose faith and stop seeing value in coaching → companies start trivializing a coaching role  companies decide not to spend more money on high quality coaching cheaper, even less effective, coaches are hired (or internal, misplaced people are refurbished into coaches, overnight, as per Larman’s Law # 4) initially, low-set coaching bar, is lowered even further…and so on….

Graphically, it looks something like this:

As a result, what was initially meant as a strategic organization- improvement effort, now takes on a form of just another system-gaming change management fad that ultimately leads to a failure and responsibility/blame-shifting.

What are some of the reasons why the above happens?  Here are some suggested reasons:

  • Companies don’t understand the essence of agile coaching role: it is viewed as another “turn-on switch” management function
  • Leadership does not feel a sense of urgency (p. 14) to make changes and exempts itself from being coached: people are too busy and too senior to be coached; they find coaching trivial
  • Certain organizational pockets are genuinely resistant to/feared of changes that can be brought about by real coaches (as per Larman’s Laws 1 – 3)
  • Market over-saturation with unskilled recruiters that hunt for low-quality coaches and contribute to the above cycle: this further lowers a company’s chances to find a good coach
  • This list can be extended….

Who is responsible for initiating this vicious cyclic dysfunction?  Does it really matter if we identify guilty ones?  Maybe it does, but only, as a lessons-learning exercise.  What probably matters more is how to break out of this cycle.  Where to start: discontinue low-quality supply (coaches) or raise a bar on demand (by companies)?  Usually, demand drives supply and if so, for as long as companies remain complacent and reliant on outlived staffing/head-hunting approaches, cold-calling techniques, and ineffective HR-screening processes, performed by people that poorly understand the essence of an agile coaching profession, while trying to procure cheap “agile” resources or treat seasoned professional coaches, as “requisitions to be filled”,  a coaching bar will remain low, and companies will be getting EXACTLY  what they have paid for: coaches-centaurs (p.17).

Big question

What should companies be looking for when hiring a coach?”

An organization should be looking much father and beyond of what is typically presented in a resume or a public profile of a candidate: usually, a chronological list of an employment history or a long list of google-able terms & definitions,  popular jargon or claims of experience in resolving deep, systemic organizational challenges with Jira configurations 😊.  Much more attention should be paid to the following important quantitative characteristics of a coach:

Coaching Focus: What is an approach and/or philosophy to coaching does a coach have?  This will help a company understand an individual mindset of a coach.

Coaching Education AND Mentorship: What active journey through education, mentorship and collaborative learning in coaching and related activities over significant period has a coach taken?

Formal Coaching Education: What has contributed significantly to a person’s coaching journey, including courses on topics of facilitation, leadership, consulting, coaching, process, and other related activities which have influenced a person’s coaching practice? Such education may not have to be degree-related (training and/or certification from any recognized institution could be sufficient).

Coaching Mentorship & Collaboration: How a coach developed a skill/technique or received guidance to a coaching approach and mindset?  Respect and recognition of mentors – matters here.

Informal Coaching Learning: What important topics outside of Agile/Scrum literature have impacted a person’s coaching philosophy?  This increases chances that a coach is well-rounded, beyond standardized book learning.

Agile Community Engagement & Leadership:  Does a coach engage in agile user groups, gatherings, retreats, camps, conferences, as well as writing, publishing, reviewing, presenting, facilitating, training, mentoring, organizing, and leading agile events?  An active participation and leadership in the agile community is a good demonstration that a coach has not developed herself within a unique organizational silo, by self-proclaiming and self-promoting, but rather has diverse and ‘tested’  industry experience.

Agile Community Collaborative Mentoring & Advisory: Does a coach mentor or advise other individuals (not for pay) on how to increase their competency or development?  Is a relationship on-going, purposeful and bi-directionally educational?

Coaching Tools, Techniques and Frameworks: Does a coach develop awareness and understanding of tools, techniques and frameworks while engaging with organizations?  Has she customized or developed anything that was client/engagement-specific?

In addition to quantitative characteristics , here are qualitative characteristics of a good coach:

Coaching Mindset
  • How does a coach react when an outcome of coaching was different from what she had desired? In the past, how did a coach address this situation?
  • How, based on clients’ needs, a coaching mindset had to change? In the past, what compromises did a coach make? What was learned?
  • What new techniques or skills did a coach learn, to meet a client’s needs?
Coaching Competencies
  • Assess – Discovery & Direction
  • Balance – Coaching & Consulting
  • Catalyze – Leadership & Organizations
  • Facilitate – Focus & Alignment
  • Educate – Awareness & Understanding
Coaching Specialties
  • Lean / Kanban
  • User Experience / Design
  • Scaling Agile / Enterprise Agility
  • Technical / Quality Practices
  • Organizational Structures
  • Lean Startup
  • Product / Portfolio Management
  • Organizational Culture
  • Learning Organizations
  • Non-Software Application
  • Business Value / Agility
  • Technical / Product Research
  • Multi-Team Dynamics
  • Organizational Leadership
  • Organizational Change

[Note: The above, is based on guidelines provided by Scrum Alliance application process for CTC and CEC.]

While running some risk of sounding self-serving (very much NOT! the intent here) : please, be mindful and responsible when you select guidance-level professionals in your agile journey 😉.

05/26-28: Scrum Coaching Retreat | Kiev, Ukraine

2017 Scrum Coaching Retreat in Kiev  is in the books!!!  The event has brought together a few dozens of agile coaches and trainers from nearby and far away.

The participants came from different backgrounds and focus areas but due to everyone’s extensive experience in self-organization and self-management, got the show on the road very quickly.  After a short round of self-intros, each participant introduced a few topics that they wanted to discuss. By using a combination of dot-voting and affinity clustering techniques, the group came up with a handful of key topics that everyone wanted to deep dive into.  The group broke up into four teams, with each team picking one high-priority topic – to be worked on in consecutive three (3) sprints.

The team I joined (“Happy 7”) picked up the topic “How to influence decisions of senior management directly, from the bottom of organizational pyramid”.  The team consisted of experienced ScrumMasters, Team-level and Enterprise-level coaches.

The problem statement that defined our team’s effort was:

“There are so many instances, of challenges and obstacles that teams face, are not being heard at the top of a food chain.  And even when they are heard, often, original messages get distorted and lose urgency, as they travel up through multiple “translational” layers.  What can be done to fix this problem?  What techniques could be used to effectively segregate impediments that are local and can be resolved by teams and the ones that are systemic/organizational – and must be aggressively escalated upward?” 

The problem above has direct dependency on organizational design, specifically, on its thickness: the number of organizational layers between working teams (on one hand) and senior leadership/paying customers (on the other) – is a well-recognized challenge today.

Our working group has identified the following organizational design scenarios that define dynamics and human interaction in modern Product Development:

  1. Development teams and Product Owner belong to the same organization and end-Customer is positioned internally
  2. Development teams and Product Owner belong to the same organization and end-Customer is positioned externally
  3. Development teams represent Vendor-company and Product Owner represents Client-company and relationships between Vendor and Client are based on:
    • Out-staffing model – when a vendor provides human assets (developers) that are then owned by a customer, from management perspective, whereas legal ownership (e.g. insurance, taxes) is still by a vendor
    • Out-sourcing model – when an entire project gets outsourced to a vendor and a paying customer has no or minimal interaction directly with human assets (developers) that do work (most of communication flows through Engagement Management)

Interestingly, since many of our working group members had a lot of experience with #3 option above, the primary focus of our discussion was about how to bring closer senior leadership of paying customers and agile teams of delivering vendors, closer together, despite multiple “anti-agile” organizational layers that frequently reside in-between the former and the latter.

The ultimate result of our brainstorming was the invention of a non-commercial, collaborative game that was given the name of Influence Poker.

Our game’s purpose was:

  • To identify challenges that delivery teams often face
  • To classify challenges, based on origin, severity and implications
  • To discuss potential ways of resolving and/or escalating challenges
  • To ensure resolution ownership and transparency on its progress

Note: The initial contributors to the game creation were: Serhiy Lvov, Kiryl Baranoshnik, Artem Bykovets, Alexander Karitsky, Mark Summers, Jonas Mann and Gene Gendel .

The most serious organizational design challenge, when a paying customer engages with a vendor-company, is seen with an out-sourcing model.  Here, no matter how agile/robust technology teams are, their ability to deliver effectively is hindered by:

  • Involvement of Delivery Manager (usually, placed on a client site) who owns a relationship with a customer, serves as a single filter-channel of communication between a customer and teams, makes commitments and furnishes progress reporting on behalf of teams. The same person also streamlines feedback from a customer back to teams and frequently assigns work to team members.  This is usually accompanied by micro-management and command and control behavior.  The situation can be further worsened by the presence of Vendor Management function (customer side) that enforces SLAs, SOWs and other formal contracts between a customer and vendor: this just adds additional tension to a relationship and moves further apart end-customers and delivery teams.
  • Weakening of Product Owner role – the importance of this critical Scrum role gets downplayed, because a customer company no longer sees value in direct communication with technology teams.  Instead, Delivery Manager is treated as a single person, responsible for project delivery.  This dramatically narrows all communication media that are used in Scrum (holding events, sharing artifacts).

The above two challenges are inter-related through a positive feedback loop: the less disengaged Product Owner becomes, the more pivotal the role of Delivery Manager becomes.  The opposite is true too: strengthening the role of Delivery Manager, leads to further “excusing” Product Owner from stepping into the game, as Scrum requires.  This is a viscous, de-stabilizing loop that continuously weakens Scrum.

Please, look out for the Influence Poker.first official release that is coming soon! It may greatly help your teams visualize their organizational problems and discover potential workable solutions.

Note: For attendees and participants, here are additional shortcuts:

2017 Agile Maine Day Recap

The 2017 Agile Maine Day event is in the books.  Great event organization. Great energizing crowd. Amazing presenters and speakers.

Below are the summaries of two selected presentations, whose themes were mostly relevant to System Thinking and System Design:

Don Macintyre’s topic “Agile Leadership” was about Radical Management (Steve Denning’s teaching) and covered:

  • Shifting focus from making money for shareholders to focus on delighting customers through continuous innovation
  • Managers focusing on controlling individuals to Managers empowering and supporting self-organizing teams
  • Shifting from controlling work with bureaucracy to guiding innovation with priorities
  • Shifting from predominantly valuing efficiency to valuing Continuous Innovation
  • Shifting from top-down command structures to horizontal communication and collaboration

Don also talked about Agile Leadership Mindset and stressed the importance of the following behavioral transitions:

  • From Directing to Coaching
  • From Hiding Failure to Learning from Failure
  • From Telling to Collaborating
  • From Avoiding Blame to Seeing Feedback

Bob Sarni’s – “Radical Collaboration” delivered the following main message: “Organizations cannot compete externally until they can collaborate internally

Bob referenced the book “Corporate Culture and Performance” by John Kotter and James Heskett: Non-enhancing Cultures vs. Enhancing Cultures, alluding to the fact that sometimes the best way to overcome resistance, is to remove resistors.

The following four quadrants of self-discovery were covered:

  • Who we are (Self-mastery):
    • Self-Awareness
    • Self-Esteem
    • Emotional Intelligence
    • Values
  • Interpersonal (Social Intelligence):
    • Communication
    • Trustworthiness
    • Cooperation
    • Rules of Engagement
  • What we Do:
    • Project
    • Product
    • Task
    • Service
  • How We Do it:
    • Systems/Processes
    • Decision Making
    • Structure
    • Policies

Bob also stressed the point that when it comes to going through organizational changes, companies tend to focus on Practices, instead of focusing on underlining Principles and Values. This results in unsustainable, short-term successes only.
Another great quote from Bob’s session: “Business Analysis have their focus on the outer side of business”, mainly focusing on questions of ‘what should we be doing?‘ and ‘how can we do it better, faster and more efficiently’.  It turns out that the inner side of the business is where the greatest opportunity for radical improvement resides”.  The inner side of the business contains the heart and soul of the business.

Finally, Bob talked about Red Zone vs. Green Zone Behaviors (refernicing work of James Tamm)


Bob also described Pink Zone behavior that usually manifests itself by the following actions: Leave, Quit, Hide, Passively Resist, Appease, Give in

(At closing, a kodak moment with Dan Mezick and Bob Sarni)

 

2017 Big Apple Scrum Day: Coaching Clinic

The Third Annual BASD (2017) event is in the books.  27 people have been served by the coaches, whose cumulative experience and depth of knowledge were just immense.  Many thanks to Zuzka Sochova, Kim Brainard, Bob Galen, David Liebman and Jim York for making this happen.  This event had the largest every presence of Certified Enterprise Coaches (CEC).

Below is the summary of quotes from the people that attended the Coaching Clinic:

  • “Awesome session. Wealth of knowledge.”
  • “Pleasant convo. Vague question but got some interesting answers.”
  • “Bob helped me with several concerns I had. He broke things down and emphasized the importance of always looking at things with a whole team approach. Will use feedback.”
  • “Dave: – great shaking, -good advice, – will use immediately.”
    “Very helpful and informative, It is always good to learn other perspectives”
  • “Great insight and way to look at personal issues.”
  • “Dave game me some good marketing advice about marketing myself”
  • “Bob listened, provided valuable feedback and helped me walk out with actionable items. Thank you!”
  • “David – useful suggestion.”
  • “Refreshing and very pragmatic session.   Great advice and specific to my exact topic.”
  • “Awesome coaching from Kim. Look forward to taking her feedback to work.”
  • “Practical & useful talk about Scrum roles with development team (PO & SM).”
  • “Great feedback from Dave. Great advice about how to run meetings and to get work done.”
  • “Great pointers to look for next steps. Good and honest advice. Informative discussion.”
  • “Got coaching from Jim on rolling out agile more broadly. Jim was really helpful and got us to the heart of where we should focus. Thank you!”
  • “Dave shared personal experiences that helped me identify possible resolutions to my problem. Very clearly followed the steps from the coaching stance. Got definite actions to try.”
  • “Great advice for retros from Kim.”
  • “Had a session with Jim about career path and my goals. He was extremely helpful. Listened to my concerns and helped with ideas.”
  • “Great therapy session! Was able to get real life examples in the feedback.”
  • “Meeting with Jim was worth every nano-second. He reset my thinking about focus but more importantly, my intention with short-term and long-term goals — but especially humility. Excellent!”


Agile Flyer – 03-18-2017

Note: This week, a few hundred of people have subscribed to Agile Flyer!
Welcome Everyone!!!
To bring them all up-to-speed, some information below is summarized from previous releases.
If you would like to read previous Agile Flyer releases, please click here


From www.ScrumAlliance.org

Connect with a Certified Coach for Online Coaching!
(re-published from Scrum Alliance newsletter)
[concequences of using]
WATERFALL REQUIREMENTS
IN AGILE PRODUCT DEVELOPMENT
  • By nature, BRDs imply conclusiveness and are “contractual” in nature, and therefore, should not be used in iterative development
  • BRDs are frequently produced by “middle men” and weakly represent views and desires of End-Customer
  • Creating BRDs, done by a separate organizational layer, frequently leads to Local Optimization
  • In Agile Development, BRDs may lead to deterioration of relationships between Product Owner and Feature Team
  • In Agile Development, the use of BRDs leads to having false expectations and reduces involvement of End-Customer

Everyone is familiar with conventional
Business Requirements Documents (BRDs).
  Usually, BRDs are written by Business Analysts – individuals representing a function specialty organizational tier – a layer that usually resides between end-customers and software engineers.
BRDs explicitly talk about “what” a customer wants from a system, including functional and non-functional requirements.
BRDs are comprehensive documents: heavy in content and with many supporting details. BRDs are based on far-reaching future plans that spans across multiple product development phases and releases.
By design, a single BRD may represent an implementation effort that takes anywhere from a few to many months.

-Read more…




THE “R” PART OF HR

re-published from last week

Frequently, HR topics find their way into Agile Communities and almost always turn into heated discussions.
Recently, and again, one of such topics was raised in the global community of Coaches and Trainers, thus sharing it here.

Truth be told, HR norms and policies are a direct reflection of organizational culture
(considered, as corollary to structure)
and very much define human relationships within an organization.
Therefore, 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 of 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?  -Read more…

More Selected Periodicals:

Handling Interruptions in Scrum: 4 Options (Part 1)

In an ideal world, a cross-functional Scrum team must be fully focused on Scrum.  The team is also expected to hear a voice of one customer only: the product owner.  But what happens when reality intervenes and you get pulled in other directions?
-Read more…

Handling Interruptions in Scrum: 4 Options (Part 2)

There are four commonly known ways that teams use to handle production support, or other “interrupt” items.  Frequently, these items are classified by “levels” of priority/criticality, with L1 being the lowest and L3 being the highest priority.  As we continue from Part 1 of this two-part article, we look at the remaining two ways of interrupting Scrum sprints–and share what can be done about them.  -Read more…

Fresh Collection of Ad-hoc Agile References:

I continuously collect articles and publications that come from everywhere: colleagues, coaches and trainers, clients, occasional encounters.
I keep a comprehensive list of resources here, categorized by themes.
Some of my most recent samples from the collection are below: