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
[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:
Connect with a Certified Coach for Online Coaching!