Software the Agile Way....

There is no TRUE way of doing retrospectives. Teams are different in motivation, competence, culture and size. What works for you, might be ineffective in my context.  For me, the key indicator of good retrospective - developed action plan to improve process. How you get there is not as relevant

Stage 0 - Discovery : Activities designed to discover opportunities and to generate new product ideas. Stage 1 - Scoping:  A quick and inexpensive assessment of the technical merits of the project and its market prospects. Stage 2 - Build Business Case:  This is the critical homework stage - the one that makes or breaks the project. Technical, marketing and business feasibility are accessed resulting in a business case which has three main components: product and project definition; project justification; and project plan. Stage 3 - Development:  Plans are translated into concrete deliverables. The actual design and development of the new product occurs, the manufacturing or operations plan is mapped out, the marketing launch and operating plans are developed, and the test plans for the next stage are defined. Stage 4 - Testing and Validation:  The purpose of this stage is to provide validation of the entire project: the product itself, the production/manufactu...

Team Formation Requirement workshop and identifying the Epics and stories Initial technical architecture Initial Release goal Secure Funding Development Environment setup  Risks identification

Values diverse opinions Cultivates a culture of trust Develops other leaders Helps people with life issues Encourages Sells instead of tells Thinks you, not me Thinks long-term Acts with humility Source- http://www.skipprichard.com/9-qualities-of-the-servant-leader/

source- http://www.industryweek.com/lean-six-sigma/7-steps-leading-lean-respect-people 

CMMI is a sophisticated method for performance management. It helps companies predict costs, create schedules, and ensure quality. There's a whole  CMMI culture  that can train someone on the CMMI models and how to use them.

Agile is a cultural change that impacts people, processes and tools in different ways across the organization; based on iterative, time boxed and incremental approach , where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams , Agile promotes adaptive planning , evolutionary development and delivery and encourages a rapid and flexible response to change . 

Some of the approaches to scale scrum are mentioned below: - Scaled Agile Framework (SAFe), by Dean Leffingwell; - Disciplined Agile Development (DAD), by Scott Ambler; - Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. Each has pros and cons and suited for different types of organisations or projects. What's more important is when we implement any practice is to track the impact of the change using hard direct evidence and see if the change is positive or negative. Look at evidence based management  to help track it.

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. DevOps is also characterized by operations staff making use many of the same techniques as developers for their systems work. “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other subdisciplines and job titles. “Dev” is used as shorthand for developers in particular, but really in practice it is even wider and means “all the people involved in developing the product,” which can include Product, QA, and other kinds of disciplines. DevOps Practices  –Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration manage...

Ward Cunningham  coined the term , and Martin Fowler has some  good takes  on the subject, and  Ron Jeffries  as well. Technical Debt includes those  internal  things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. Technical Debt doesn't include deferred functionality, except possibly in edge cases where delivered functionality is "good enough" for the customer, but doesn't satisfy some standard (e.g., a UI element that isn't fully compliant with some UI standard). During the planning or execution of a software project, decisions are made to defer necessary work. For example: It's too late in the LifeCycle ?  to upgrade to the new release of the compiler. We'll do it next time around. We're not completely conforming to the  UserInterface  guidelines. We'll get to it next time. We don't have time to uncruft (refactor, see  RefactorMercilessly ) t...