In my previous posts we looked at symptoms of bad code and reasons we write bad code. And bad code leads to technical debt. Ward Cunningham introduced the Technical Debt metaphor by stating: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with…
In my previous post, I discussed symptoms of bad code. Here I’m going to look into some of the reasons we end up writing bad code: Deadlines - You’ll hear excuses like we have a deadline to meet so we don’t have time to test or to make the necessary design change.Broken Window Theory - Another…
Check out the video below of Jeff Gallimore presenting on "Decoding Culture: Beyond the Fluff and Back to Business" at Washington DC Scrum User Group (DCSUG). Jeff explores how culture connects to organizational performance, vocabulary for how to describe culture, research about the effects of culture, and tactics you can use to change your culture for…
Bad code tends to creep up on us over and over again. We’ve all been there. We kick off a project, things start a little slow, but then things quickly pick up and a lot of features are getting developed and delivered. We have an excited team and a happy customer. However, soon things start to…
Check out the video below of By Kent Hone and Mark Grove presenting on " Kanban in Action: Thoughtfully Observing Flow" at Washington DC Scrum User Group (DCSUG). Kent and Mark provide a detailed look at how to interpret and thoughtfully observe Kanban Boards to better understand the work of your teams. They start with an…
Congrats on completing your Certified ScrumMaster (CSM) class! Now it's time to take the CSM exam as per the instructions sent to you by the Scrum Alliance. For the exam, I recommend you read the Scrum Guide, review your workbook and notes from the class and read the Scrum in a Nutshell Series. Remember, you have…
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase. The…
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal.…
Check out the video below of William Strydom presenting on "Servant Leadership" at Washington DC Scrum User Group (DCSUG). William explores what servant leadership is and where servant leadership came from along with examples of servant leaders in our world and where to find more information about servant leadership. https://youtu.be/XqEqdZ56Xko Servant Leadership by William Strydom
When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Scrum Team and is…
The Product Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment…
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a…
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when…
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. A Product Backlog is never complete. The…
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact. these are the Product Backlog, the Sprint Backlog, and the Product Increment.