This week I’m listing out the tools that we use in an average iteration, focused on what helps us on our Agile Journey. I will expand a little on how and why we use them. Basic office and job tools such as furniture and email are not being mentioned. Assume that we have a Microsoft tool for basic things like this that are not mentioned. Continue reading
The next value pair starts fairly easily with working software.
While there are nuances that can be debated over it doesn’t take long for the act of debating them to devolve into little more than meaningless mental exercises. Changing this from “Working Software” to “Complete Products” may help when trying Agile in non-software environments.
The second half of this one, comprehensive documentation, this is the one that most people miss the meaning of when looking at Agile. This one could be debated for a long time. Unfortunately the only generic “right” answer for what it truly means is “it depends.”
I have written about estimation before. I have written about Planning Poker before. Today I am going to do a simple beginners guide to Planning Poker. The difference is that this guide is meant to be used by you. You could use it as a presentation presenting the idea of Planning Poker. Alternately it can be used to teach a team and run the first session. With that frame of reference in mind let’s get started.
How many of you like to estimate as a team? I do. I find it an easy process with lots of value for everyone involved. What if I taught you a method that will get your team rapidly reaching a consensus while estimating? These estimates will be accurate enough for iteration planning. As a side benefit, the team will have a better understanding of the product and its future direction. The process is lightweight enough to keep the team engaged. The end result is estimation meetings that are not dreaded by anyone. Continue reading
The Product Owner. Part of the team; apart from the team. The final answer to the question “what?” The primary respondent to the question “why?” She knows what the users want. He understands what the users need.
The Product Owner (PO) has a great amount of power. (And responsibility – “With great power comes great responsibility.” – Stan Lee via Uncle Ben) The PO ensures the Development Team produces value. In scrum the PO is the keeper of the Product Backlog. The PO is one person. The PO is the final authority for the product. The PO role is not to be taken lightly. It must be given to the proper person. Who that right person is depends on a lot of factors. Continue reading