Software the Agile Way....

All projects have risks and the risks have the potential for negatively impacting the project. (I am not referring to opportunity (positive) risk.)   Try to Include Budget and Schedule for Unknown Risks A project manager can request additional budget and schedule to account for known risks at the beginning of a project. Of course, the risk contingency does not include the full impact of risk. Instead you multiply impact by the percentage likelihood for all high risks. Then add the numbers to come up with a risk contingency budget and schedule. However, risk identification is not something that only happens at the beginning of a project. The project manager assesses risks throughout the project.  Therefore, it makes sense to include time and budget for unknown risks as a part of your estimating process. If you do an effective job of periodically reassessing risks, you may find new risks to manage that were not included in the original risk contingency budget. You can...

Source: (The Standish Group, 2011) Lack of top management commitment Scrum demands commitment from the top management through the assignation of a full-time cross-functional self organized team. The team is protected and can take their own decisions about the project with the support of the top management. Failure to gain user commitment In Scrum, the team constantly show working software to the users, which increase the commitment and feedback. Misunderstanding the requirements Scrum knows that is not possible to fully understand all the user requirements. In each iteration, the team work in the more important and clear requirements. As the software is developed, the team get better insights about the project goals and have more clarity about the following requirements. Lack of adequate user involvement Constantly working software makes the users more involve in the process. Lack of required knowledge/skills in the project personnel In Scrum, the teams are cros...

Spike are type of Story that are used for activities such as research,design,exploration and even prototyping. Functional Spike- It is used to list out the scenarios which can influence the implementation. Technical Spike- It is used to determine the Feasibility and impact of design strategy.

Encourage employees to disagree with you.  Companies get into trouble when everyone is afraid to speak truth to power. "If all you hear is how great you're doing, that should be a danger sign," says executive coach Ray Williams. Don't micromanage.  Empower the people below you, then leave them alone. "A good part of leadership is stepping back," says Bill Pasmore, senior vice president at the Center for Creative Leadership. "A good leader leads from front and back." When people err, don't destroy them. But make sure they learn whatever lessons there are to be learned from their mistakes. Show compassion.  "Develop strong interpersonal relationships at work, so employees have some meaning attached to the work they are doing," Williams says. Vow to be constantly learning and curious. Pasmore advises taking risks and asking yourself, "What is it that I don't know that I should know? How do I learn it and test it out ...

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...