#openagile

http://bit.ly/MNUOZs

The Daily Scrum is designed to dramatically improve transparency among Scrum Team Members and out to any stakeholders who are interested in observing the meeting.  The timebox is a fixed limit on the duration of the meeting.  The 15 minute limit on the Daily Scrum is sufficient for each Team Member to take a turn and briefly answer each of the three questions required in the meeting.  The timebox forces the Team Members to be brief, to be focused, to be on-topic and to be respectful of other Team Members’ time.  If the Daily Scrum meeting takes longer than 15 minutes, some Team Members and stakeholders will stop feeling like the meeting is worth the time investment, particularly since it is daily.  Even five additional minutes for a 12 person team adds up to a person-hour of time lost every day!  Losing people’s interest or respect for the meeting will decrease transparency and can hamper the team in numerous ways, including the ScrumMaster’s ability to see and deal with obstacles in a timely manner.

From The Scrum Guide, page 5:

The Scrum Team

...Self-organizing teams choose how best to accomplish their work.

The Product Owner

...The Product Owner is the sole person responsible for managing the Product Backlog....no one is allowed to tell the Development Team to work from a different set of requirements.

A healthy dissonance is implied by the two statements above wherein sometimes a team will make decisions regarding technical implementation which may cause re-ordering of future backlog items or (possibly) re-factoring of past/done backlog items. And sometimes a Product Owner will want to impose specific rules or constraints regarding *how* the backlog items should be done.

I found myself in that uncomfortable (dissonant) place this past Sprint wherein I felt that a team member had injected a "different set of requirements" into our team's flow -- i.e. a uni-lateral decision about technical implementation. I felt this may cause us to re-work finished(past) items or may make next(future) items far more complex than first thought.

What should I, Product Owner, have done? What would you have done?

I chose to stand behind the first statement above: "Self-organizing teams choose how best to accomplish their work." This implies to me that a Product Owner should not impose or define the manner in which backlog items are done. So I remained quiet as the team members researched and discussed the matter.

It appeared at first that other team members were open to the new requirement and I became worried that this will significantly change the scope of the project. If scope was going to change or if the team would have to re-factor past/done tasks then I'd have to inform our client of the team's decision. However, after sufficient understanding, testing, and with truthful communication between team members, the consensus of the team was that the new technique being suggested, while awesome, does not suit the needs of our current project.

In fact, even the team member who originally suggested the new method/technique is in total agreement with the team's ultimate decision.

I prepared a presentation about "Team Dynamics" and invited business-minded folks to attend the live event at Sawridge Inn & Conference Centre in Fort McMurray on January 13, 2012.

I have decided to also webcast and record the event using Vokle.com. Enjoy!

The Project Management Institute has awarded me their "Agile Certified Practitioner" designation.

I received email this evening from the Project Management Institute that I have passed the examination and have met the requirements for PMI-ACP.

A summary of our society's bylaws in under 5 minutes. These will be submitted to Alberta on October 7th.

OpenAgile is a learning system designed to help individuals, teams, and organizations build capacity for rapidly delivering value to their stakeholders. Rather than the focus being on a product, the aim shifts to learning and value. Yes, the ‘product’, if there is one (software or other), is important, but now there are even greater possibilities for the use of agile outside of software. Though almost deceivingly simple, the principles animating OpenAgile are extremely profound.

In September 2010, I set out to become deeply involved with the OpenAgile Institute -- which is a group of people striving to help others become better learners, develop their unique capacities/strengths, and to reach their true potential. Put another way, it's a bunch of people who are revolutionizing the practices of project management, team administration, and teaching and learning.

Well, I'm writing this merely to say "I've levelled up!" I'm now a "Certified OpenAgile Team Member". My certificate is online here.

OpenAgile, currently, is a rather obscure practice but interest is growing quickly among people in many markets: oil, banking, higher education, non-profit administration, sales and advertising, and software development. I currently share this honour with 14 others and I'm looking forward to the next goal: to be recognized as an "OpenAgile Process Facilitator".

I wish to thank the fine friends and colleagues who helped me to achieve this goal:

Garry Berteig

Bill Prouten

Mishkin Berteig

Mike Caspar

Paul Heidema

Kory Gibbs

All the others at OpenAgile Champions forum

My team (students)

For More Information

The OpenAgile Wiki has great information.

Here's how you can become an OpenAgile Team Member