Agile Development in 3 Simple Steps
Entradas
Why should we work with Scrum Methodology in our company? Here are a few reasons why Scrum works: 1) Emphasis on communication. Scrum promotes communication between our project team members, as well as between our clients and us. It also promotes a good team work attitude. 2) Quick results. On average, a couple of iterations (sprints) is sufficient to show a working product to the client. This way, we get early feedback which helps shape the work ahead. 3) Focus on what is important. Since all the items are prioritised based on their business value, no time is wasted developing what is not important. 4) Fair time estimates. Since the production team is involved in the estimating of the Product Backlog cards, the overall time estimate is fair and square (accurate). 5) Self organisation. The production team is a self-organised unit that works to reach the Sprint Goal on time. A mix of skill sets and skill levels are often ideal to promote a continuous work flow. The ideal Scrum team form
Management 3.0 - From the book "How to change the world" by Jurgen Appelo Complexity Thinking Simple models, supported by inspiring stories, are good to get you started with the basics of change management. The real world, however, is far more complex than what most models would have you believe. We need a more complete approach to organizational change. It is very hard to predict how a complex social system will behave. We need to understand how to influence the whole system by poking at it. Then we see how it responds. As change agents we try to nudge people, teams and organizations so that they will reorganize themselves. “ The trick, as with all the behavioral possibilities of complex systems, is to recognize what structures contain which latent behaviors, and what conditions release those behaviors - and, where possible, to arrange the structures and conditions to reduce the probability of destructive behaviors and to encourage the possibility of beneficial ones. - Donel
A Scrum Master Is Not a Project Manager Contrary to popular belief, the ScrumMaster and project manager roles are highly different and shouldn't be confused. As more companies migrate their project management to Agile, many do so without a proper understanding of what they're aiming for. In particular, there are incorrect assumptions made about the roles in Agile; people often expect that the shift from Waterfall practices includes a wholesale shift of roles. The ScrumMaster, however, does not play the part of the traditional project manager. In fact, the ScrumMaster is an entirely new role. (If you're looking for the project manager within Agile, you'd be better off looking to the product owner.) Who does what? Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The ScrumMaster's role is more that of coach a
The Product Owner - Responsibilities The Product owner (or Agile PM) shoulders all the responsibility for Project success and is ultimately responsible to the Team, stakeholders and to the company. With so much at stake it's easy to get bogged down or revert back to old ways and the whole team suffers as a result. In order for Scrum to work the Product owner has to focus his time on activities that matter. 1. Creates and MAINTAINS the Product Backlog . I emphasize MAINTAINS as this is an on-going job and more than likely a full-time activity. Nothing is constant in the world of software and it’s important that the Product Owner keeps his/her eye on the ball. Note: the Product Backlog must be groomed prior to the Sprint Planning Meeting in order for the team to remain productive. 2. Prioritizes and sequences the Backlog according to business value or ROI (there are lots of tools to help Product Owners do this and lots of books on the subject) The Product Owner is required to have
Leading Agile Developers, Developing Agile Leaders Agile management is an often overlooked part of Agile. There are at least a hundred books for agile developers and project managers, but very few for agile managers and leaders. However, when organizations adopt agile software development , not only developers and project managers need to learn new practices. Development managers and team leaders must also learn a different approach to leading and managing organizations. Several studies indicate that management is the biggest obstacle in transitions to agile software development. Managers need to learn what their new role is in software development organizations in the 21st century, and how to get the best out of Agile. "Jurgen Appelo"
Differences between Waterfall, Iterative Waterfall, Scrum and Lean Software Development Waterfall Development ‘Waterfall Development’ is another name for the more traditional approach to software development . It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development ). In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed . As such, you better get whatever you’re doing right the first time ! This approach is highly risky , often more costly and generally less efficient than more Agile approaches. The main issues with this approach include: You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development ) You leave the testing until the end, which means you’re leaving issue discovery until late in the day You don’t seek approval from the
Scrum vs Kanban
Scrum vs Kanban SCRUM BOARDS Scrum boards are for teams who like to plan their work in detail before they start a project. This usually includes creating sprints and giving story points to user stories in order to plan which story can go to which sprint. When you first create a Scrum board, you create a list of items which becomes the backlog. From there, you create different versions and sprints and move the issue from backlogs to sprints. Scrum boards have a Plan mode and a Work mode. The Plan mode, as explained above, includes moving issues from backlogs and giving each one a time estimate. The Work mode is the actual board itself, where you can move cards (issues) across columns (statuses). KANBAN BOARDS Kanban by contrast allows users to start work without necessarily having a structured plan, and in fact does not even have a plan mode. The Kanban work board uses the same column-based interface as Scrum for tracking the status of tasks, however without the ability to organize thes
