Software the Agile Way....

Agile release planning is best accomplished via the straightforward method of getting everyone into a room together. Everybody who will be involved in the release should participate in the planning. That gives us a potential invite list that looks like this: ·          Scrum Master ·          Product Owner ·          Delivery Team ·          Stakeholders ·          Outside experts ·          Customer(s) ·          3rd Party Vendors ·          Marketing ·          Sales When all of these people gather and work together on the release, marvelous things can happen. A Release Planning agenda might look like this...

1. Iteration is too short and stories are big ( Can't get things done in 2 or 3 weeks) 2. We need experts 3. Team formation by layer/component 4. Experts estimating 5. We must have overtime 6. We don't have technical debt 7. Featur-itis

1. Changing old ways of thinking  Learn Scrum well, read lots and talk to people that have done it. Be willing to learn.  2. Be a servant leader and coach.  Learn to let go and not manage. Attend courses on how to coach.  3. If you have just learnt Scrum, don't try transform an organisation into agile.  Be a Scrum Master in a team, but hire a person that has experience in changing an organisation. A good transformation coach will help you learn to really run a team and not theoretically.

Mentor other team members  Challenge other team members  Involve with other team members in Decision Making Appreciate other team members Listen to other team members Respect other team members

During Refinement meeting, team +PO should assess the below pointers: Requirements that are clear; we foresee no significant changes Requirements that are incomplete; we foresee moderate changes Requirements that are ambiguous; we foresee many changes Requirements that are potentially missing or implicitly stated These pointers can help in budgeting and costing a project.

Lean manufacturing started with Henry Ford, who not only concentrated on material flow by linking manufacturing operations, but understood that, "Having a stock of raw materials or finished goods in excess of re­quirements is waste." He prevented the storage of ma­terial in any stage of completion by not having a single warehouse. After World War II, Taiichi Ohno and asso­ciates, including Shigeo Shingo, built on Henry Ford's ideas and developed the Toyota Production System, described as "a reasonable method of making products since it completely eliminates unnecessary elements in production for the purpose of cost reduction. The basic idea in such a production system is to produce the kind of units needed, at the time needed, and in the quanti­ties needed." Toyota focused on reducing cost, and on developing continuous flow for low-volume production. Lean manufacturing puts an increased emphasis on adding value. In a mature, lean manufacturing environ­ment, pro...

·          Change Agent : Should work as a change agent as there will be plenty of changes while we transition into Agile world.   ·          Create / build agile framework while taking the current technology/methodology environment that is currently in place and ensure for smooth transition.   ·          Should think big and frame/execute agile methodology at program level.   ·          Facilitator : Facilitate the team with the knowledge so that team can start the project.   ·          Trainer : Provide training to the team on the agile process; training will continue all the time during the project execution on agile and continuous improvement on velocity, quality, processes etc.   ·          Help in prepari...

User story-  As a product owner, I would like to get an web based email program by which I can compose email on-line and can send email. TDD-  This program should send email if To address is valid. This program should send email if CC address is valid even if To address is not valid This program should send email if BCC address is valid even if CC and To address is not valid. This program should send email even if the subject line is empty. This program should send email even if the body is empty. Problem in this - T here might be some more test cases if the option stated in 1, 2 and 3 are altered. Even there might be more test cases if he considers the format of the body of the email (like plain text, rich text or HTML). If the body is HTML, then he needs to think about the HTML encoding things. BDD- Given  that a web based email module has been developed And I am accessing it with proper authentication When  I shall write sender email address i...

BDD is usually done in very English-like language helps the Domain experts to understand the implementation rather than exposing the code level tests. Its defined in a GWT format, GIVEN WHEN & THEN. Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design Instead of writing tests you should think of specifying behavior. Behavior is how the user wants the application to behave. When your development is Behavior-driven, you always start with the piece of functionality that’s most important to your user. I consider this phase as taking the developer hat off and putting the user hat on. Once you've specified the user needs, you put the developer hat back on and implement your specification. Test-driven development focuses on the developer’s opinion on how parts of the software should work. Behavior-driven development focuses on the users’ opinion on how they want your application to behave.

http://www.isixsigma.com/tools-templates/sipoc-copis/sipoc-diagram/ The SIPOC tool is particularly useful when it is not clear: Who supplies inputs to the process? What specifications are placed on the inputs? Who are the true customers of the process? What are the requirements of the customers?