RE: [epf-dev] BUP Fundamental Concepts and CollaborativePrinciplesPropos

[salhir@xxxxxxxxxxx (Sinan Si Alhir)]

Thanks for the reply and feedback, Steve, I am indeed interested in collaborating.

 -------------- Original message ----------------------
From: "WSA Consulting Inc" <steve@xxxxxxxxxxxxxxxxx>
> He Sinan:
> 
> This is great stuff. But be careful because I think your email says you're
> offering to collaborate on creating the BUP collaborative principles. :-)
> 
> Steve
> 
> -----Original Message-----
> From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Sinan Si Alhir
> Sent: Monday, April 03, 2006 7:04 PM
> To: epf-dev@xxxxxxxxxxx
> Subject: RE: [epf-dev] BUP Fundamental Concepts and
> CollaborativePrinciplesProposal [*]
> 
> Good reference to Boyd.
> 
> The following (which encompass Sun Tzu,  John Boyd, and much more, etc.) may
> be of interest:
> 
> * The Agile Unified Process (AUP)
> http://salhir.home.comcast.net/TheAgileUnifiedProcess.PDF
> 
> * The Art of Agility and the Agile Unified Process (AUP)
> http://salhir.home.comcast.net/AoA-AUP.PDF
> 
> * The Art of Agility: Project Management and Software Development
> http://salhir.home.comcast.net/AoA-PMSD.PDF
> 
> * Market Dominance: Beyond Agility
> http://salhir.home.comcast.net/AoA-MDBA.PDF
> 
> S. S. A.
> salhir@xxxxxxxxxxx
> http://salhir.home.comcast.net
> 
> 
> ----------------------------------------------------------------------------
> ----
> From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of steve
> Sent: Wednesday, March 29, 2006 1:42 PM
> To: epf-dev@xxxxxxxxxxx
> Subject: [epf-dev] BUP Fundamental Concepts and Collaborative
> PrinciplesProposal
> 
> 
> Hello everyone!
> 
>  
> 
> I've created a very, very low fidelity (vvlo fi) mockup of a possible BUP
> welcome page and subsequent guidelines pages (it's a good thing I don't make
> my living as a web page designer). The purpose of this mockup is to propose
> that we specify from the welcome page BUP's fundamental concepts,
> collaboration, iteration, architecture, requirements management. I am
> presenting this to you to begin a discussion of how to capture and present
> to BUP users our intentions behind BUP. 
> 
>  
> 
> This effort began when I started thinking how we could include collaborative
> principles into the BUP. For this I turned to the agile methodologies
> because they are more about collaboration than specific software development
> techniques. In my view the success of the agile methodologies is how their
> principles capture and communicate the intention of the methodology
> designers to the users. When the methodology users understand the intention
> behind the methodology, then it becomes much easier for the users to apply,
> adapt, and grow the methodology to fit their specific needs. 
> 
>  
> 
> Therefore I believe the best way to communicate our intentions to BUP users
> is to capture our intentions a set of principles rather than specific rules,
> tasks, and guidelines. These principles of course shall help guide users
> understand BUP tasks, and guidelines and more importantly give them the
> confidence to know how to apply and adapt them. These principles are really
> patterns and in the examples I have drawn a couple of example patterns from
> "Patterns for Effective Use Cases" and from "Organizational Patterns for
> Agile Software Development".
> 
>  
> 
> One thing I would also like to point out, I have been conducting an informal
> survey of groups who have dumped RUP in favour of an agile methodology. Ok,
> I only have three data points, but they are from some rather large IT shops
> like the National Institute of Health and Ameritrade. In a nutshell, these
> groups adopt agile methodologies because they want an iterative methodology.
> How is that for a kick in the place that hurts the most? The RUP is so
> overwhelming that it is not seen as an iterative methodology. 
> 
>  
> 
> Therefore I want to distill BUP into a set of guiding principles, that are
> easy to remember, can be easily taught in a one (or two day course) and
> immediately put into practice by a software team after the course. The
> specific practices, roles, tasks, work products, guidelines, etc. all become
> like a BUP reference or specific how to. But the fundamental understanding
> comes from the principles which are included as part of the methodology.
> 
> Tour and explanation of the pages:
> Splash Page and Fundamental Concepts
> As a bit of humour towards our name debates I've code named our process
> TPFKB (The Process Formerly Known as BUP). The welcome page gives the vision
> for TPFKB (an iterative process that is minimal, complete, and extensible).
> Following this is the infamous hump diagram (can we use this or are we
> violating copyright? Finally the meat of this discussion, the BUP
> Fundamental Concepts, collaboration, iteration, requirements management, and
> architecture. I have given each of these concepts a memorable metaphoric
> phrase to capture its intent, therefore collaboration is "it's the people",
> iteration is "do it again, and again, and.", requirements management is
> "know what they really want", and architecture is "long live architecture".
> The "long live architecture" metaphor has multiple meanings. One meaning of
> course is the intention that our objective with architecture is to create an
> architecture that sustains the long term evolution of the system. The other
> meaning is to defiantly d
>  eclare the discipline of software architecture is still important.
> 
>  
> 
> These fundamental concepts are intended to be headliners to longer
> narratives that describe the essence of the concept. In our language, these
> headliners are pattern names and the narratives are like patterns, captured
> knowledge that may be shared. I've been reading through a number of papers
> that relate fast cycle times (the core of agility) to heuristic narratives
> that help people take the initiative within the organization in a harmonious
> manner. In my humble opinion, this is what we must capture and build into
> the methodology. 
> 
>  
> 
> You will also notice that I included on this page a section called Project
> XYZ Guiding Principles. This opens up the opportunity for a development
> organization to include project specific "guiding principles" In this
> example I used principles that are specific to a client that I am currently
> working with (we are using BUP on this project). They are re-engineering a
> legacy system and you know how easily legacy replacement projects can go off
> track, hence a set of specific principles that we harp on again and again to
> keep the developers focused on what is important.
> 
> It's the People
> If you follow the link to the "It's the People" page you will see how I may
> describe collaboration. First I start with why collaboration is important,
> because success through agility is based on culture. In my personal opinion
> we must emphasize this concept that success is a rooted in culture. The
> agile methodologies have successfully publicized the importance of culture
> and if BUP is to meet our goals we must do likewise. The text that first
> appears here is derived from USAF Colonel John Boyd's study of strategy and
> fast decision making cycles. 
> 
>  
> 
> The collaborative principles are intended to be the half dozen or so
> "guiding principles" or patterns from which emerges the collaborative
> culture. I have included a few patterns from various sources to provide an
> example of what these patterns might be. I have tried to give the patterns
> metaphoric names. However you have to remember I have a twisted sense of
> humor and I can already guess that a name like "come to Jesus" isn't going
> to go over well with most people. Just as an aside, that name is really a
> place holder for a "retrospectives" guideline or pattern. The phrase "come
> to Jesus" is apparently the slang used by employees of Southwest Airlines
> for their weekly retrospective meetings.
> 
> Share the Vision
> If you follow the Share the Vision link you will see the pattern (or
> narrative) for share the vision. This specific pattern is taken from
> "Patterns for Effective Use Cases". It describes the problem, the forces and
> the solution. What is relevant to BUP is the additional sections that show
> specific BUP practices (or as I joked TPFKB) support this pattern. In this
> example I just quickly wrote down that tasks like Define Vision and work
> products like Vision support this principle. This connects specific BUP
> practices to the guiding principles and helps BUP users understand the
> intention behind the practices and the work product. 
> 
> So Where to From Here?
> I don't know if you agree my proposal for the welcome page, but I would like
> to start the process of creating the collaboration principles. So that is
> that is the task I want to propose is that we (I guess "me") create and
> write a set of collaborative principles that are an intrinsic BUP feature.
> So before I start plunging head long into this I want some feedback and a
> casual straw vote on whether capturing collaborative principles in this
> manner as either narratives or patterns is a good idea. I believe linking
> the principles to specific BUP work products and tasks is important. I'm
> hoping that a few of you are also going to jump up and say "good idea Steve,
> can we participate in this?" J 
> 
>  
> 
> Chat with you all tomorrow.
> 
>  
> 
> Best regards,
> 
> Steve Adolph
> 
>  
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
> 
> 
> 
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev