A frequent inhibitor to effective development process is misunderstanding of the intended structure and outcome of the recurring events in a batch development cycle/sprint/iteration. I am frequently asked to provide a clear, comprehensive example of how an effective development cycle should be structured.
One more entry to close out February!
This week’s addition to The Hawkins Compendium is the Development Log artifact. Second only to the Batch Cycle Planning and Tracking Guide, this is another highly-requested item.
Launching The Hawkins Compendium with the Batch Cycle (Sprint/Iteration) Planning and Tracking Guide
For well over a decade, clients and colleagues have asked that I publish some of my guidance and training on all things Product Development so they could make use of it.
I am happy to announce the launch of The Hawkins Compendium, a curation of material I have developed over the years while leading development teams and organizations to greater levels of productivity and collaboration.
When we learn new things from grappling with problems, it is natural for us to want to share those learnings with others, in hopes that they will face similar challenges with less of a struggle.
How do those well-intended new ideas so often evolve into movements that seem to lose their way, and at times do more harm than good?
In the course of observing and at times being involved in this phenomenon, I sought to understand what I saw happening time and again. Almost a decade ago, I arrived at an explanation that I named The Myth of Commoditized Excellence. What follows are the steps that can lead down this unfortunate path.
Team composition and roles can vary widely across development teams. The type of product being developed, team charter, organizational culture, and industry norms all impact whom we place into teams.
When taking an agile approach to product development, what commonalities should there be across teams as far as roles and responsibilities?
What does it mean for a team to develop software in an iterative fashion? In the wash of various processes within the agile ecosystem, iteration has come to be an overloaded term used with little thought to its purpose or the context for those systems.
The focus for this article is not iteration upon the products in the team’s portfolio, but rather the team iteratively delivering the work in their backlog.
In my experience, a healthy iterative cycle for a team involves three phases: Commit, Execute, and Evaluate.