Kanban is gaining popularity in project management circles as more teams relate to its principles of visualizing workflow, limiting work in progress and balancing demand. Here, a self-described “pragmatic Agilist” explains what drew him to Kanban, where it delivers benefits, and how it differs from other agile methods.
8 items found
A Kanban-based approach to sprint planning can produce a number of benefits, particularly when it comes to limiting work in progress. Through mechanisms that uncover impediments and prioritize items, Kanban can help to create more productive sprints, more engaged teams and more satisfied stakeholders.
You have a role in the organization’s effort to be more agile. Don’t think it will be a thankless effort, though. If you play your cards right, you can attain documentable evidence of your leadership and improve your career advancement.
The flat backlog is appropriate for keeping the team focused on the big picture for relatively small projects. However, for large enterprise project with geographically dispersed teams, a more efficient alternative to the flat product backlog is User Story Mapping--along with constant focus on the product vision and the product roadmap.
Keys for Agile Co-Evolution of the WBS and Schedule Network: The "Schedule Network 100 Percent" Rule and the "Add and Prune Dependencies" Algorithmby
The pressure for greater agility in project management approaches increases the challenge of achieving coherence between the WBS and the schedule network. This article elaborates on best practices where the goal of full coherence between the WBS and schedule network can be taken for granted and maintained without effort by the project planner.
When you’re a project manager for a traditional project, it’s easy to write a project charter. On an agile project, is that the right thing to do? Should you even use the same template? Here are some fundamental steps to get your project or iteration started on the road to success.
What are the boundaries around your project? When it comes to projects, this writer likes to turn this question inside out--how far do we have the freedom to go? The best and most productive agile teams strike an effective balance between reasonable boundaries and freedom to explore. Just look at kids for proof...
Some people see agile projects as knowledge transfer deserts where information is hoarded by key individuals and no useful documentation produced. Others believe agile projects are all about knowledge transfer. So why the disagreement? How can smart, experienced people have such different views about the same topic?