Agile Methodology

Sure why certainly? Not since you assume it's a must to, or as a result of all people else is doing it. Solely do it if there's a actual drawback that you just wish to clear up. To call a couple of examples: When you have issues with delivering software program on the proper time. In case your tasks spent an excessive amount of cash for too little worth. When you assume you possibly can’t sustain with market developments. Simply keep in mind that Scrum isn't the Holy Grail. It is not going to clear up your whole issues, and when carried out badly it would very nicely make issues worse.

If everyone within the staff has the function of developer, how do you forestall someone to develop a bit of code and deploy it to manufacturing himself? There are a number of methods to mitigate this threat. Though everyone has the function of developer, you possibly can nonetheless have a number of authorizations throughout the staff. You possibly can assign the authorization to deploy to manufacturing to a selected particular person, for instance the Scrum Grasp. One other approach is to ensure deployments can solely occur by pre-defined processes, that ideally are automated. In these processes a variety of controls needs to be build-in to keep away from misuse or errors. I'll talk about extra on this within the Steady Supply and DevOps components of this web site.

The result of every sprint is an increment, which is potentially shippable software. Weather the software will actually be release to the customer is a business decision. So no, you don’t have to go to production every sprint. But because you can, IT becomes a business enabler, instead of the department everybody is waiting for.

A user story can be seen as a requirement. It clearly describes what is needed for who and why. It is often written in the format: As a role I want something so that I can do some kind of benefit. User Stories can vary in granularity. If defined generally it is usually called an Epic. When User Stories are prioritized the team should refine them, so you end up with User Stories that can be implemented in one sprint. When selected for a sprint the Team defines Tasks to implement the User Story.

The Velocity of a team is the amount of Story Points the team can implement in one sprint. Unlike Function Points, Story Points are not comparable between teams. Every team build up its own measurement system for Story Points. Every team is challenged to improve their Velocity. The Retrospective is one of the instruments to achieve this.

The Agile manifesto was introduced in 2001 as an answer to problems with the Waterfall approach. It consists of 12 principles to better cope with uncertainty, stimulate creativity and enhance effectiveness. Since the introduction many types of Agile methods surfaced, based on the Agile principles. Scrum is currently the most popular of them, mainly due to it’s simplicity. Other types are: Extreme Programming (XP), RUP, DSDM, Kanban and Lean Development.

Where Scrum is a process framework to manage complex product development, Extreme programming (XP) is a software development methodology. Both are based on Agile principles. XP takes out beneficial elements of traditional software engineering practices, and brings them to "extreme" levels. (Hence the name). Examples of these elements are: pair programming, code review and unit testing. The four basic activities of XP are: coding, testing, listening, and designing. Like Scrum XP is designed to improve on productivity, quality and adaptivity. But in XP changes are allowed during iterations. In Scrum the scope is not changed during the sprint. Iterations in XP can be even shorter than the sprints of Scrum and the order of the XP-backlog is more strict. And last but not least: XP describes engineering practices, where Scrum only focusses on the framework.

KanBan may look a lot like Scrum, but this is mostly because many teams use Scrum elements in their KanBan approach. KanBan is a LEAN technique that optimizes the flow of a process. Think of your process as an assembly line. By limiting Work In Progress KanBan optimizes the amount of output of the assembly line. Where Scrum periodically (every 2-4 weeks) delivers an increment, KanBan constantly delivers output. So out-of-the-box KanBan does not have sprints, stand ups, retrospectives, cross-functional teams and burn down charts. KanBan does not prescribe roles and events. Even prioritization of the backlog is optional in KanBan. KanBan does have a KanBan board that may look a lot like a Scrum board. The most important thing is that you limit the amount of tasks in progress. This forces the team to finalize the ongoing tasks before starting new tasks. So if you do not really deliver increments, and if you struggle with the duration of sprints. If you consider very short sprints. Or if you have a pretty standard process that constantly delivers output. Then maybe KanBan is a better choice than Scrum. The best way to find out is to experiment with it.

A lot! Most of the times culture has to change. And culture means behaviour of people. There will be opposition. People will mock it. Conservative parties will demand proof. They will want to see solid business cases before any approval is given. In the beginning it is often swimming against the current. You have to be determined. Don’t give up easily. Check out the Pitfalls for more details.

It may seem a little impractical to limit the team size to 9-10 people. Why not 11 or 15 or 20? If you have enough work, why not? Scrum Teams are self-organizing and cross-functional. They decide for themselves how to do the work. So too few people in the team is also bad. It is very likely a team of 2 or 3 will not have all the skills to deliver increments autonomously. If the team size goes above 9 the amount of coordination will be so high the team starts to be inefficient. Bringing in more people does not mean the team will deliver more work. Quite often the opposite applies. If you really have more work than a team of 9 can handle; split the team in 2 separate Scrum teams. And do not forget: experiment! Find out what the optimal team size is for your organization by trying different sizes. Remember Scrum is empirical.