Check out our first video “Kanban Basics”.
Michael Badali is a Kanban expert with years of experience in Kanban and other Agile methods including nearly 2 years working as an internal coach at HP in China and the UK.
Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum. Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:
| ScrumMaster | Product Owner | Project Manager | Team Lead |
| NEVER | NEVER | Assign Tasks | YES |
| NO | PARTICIPATES | Create Schedule | NO |
| NO | YES | Manage Budget | NO |
| Remove Obstacles | PARTICIPATES | YES | YES |
| NO | Define Business Requirements | PARTICIPATES | NO |
| NO | YES (Deliveries) | Define Milestones | NO |
| Facilitate Meetings | NO | YES | YES |
| YES (process and people) | YES (business) | Risk Management | PARTICIPATES |
| Organizational Change Agent | NO | NO | NO |
| NO | Accountable for Business Results | RARELY (just costs) | NO |
Of course, there are many other ways we could compare these four roles. What would you like me to add to this list? Add a comment with a question or a suggestion and I will update the table appropriately!
Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams. Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram. If you give someone a map, they tend to assume that all of the exploring has already been done. If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored. Maps and diagrams do serve a purpose. They are useful. What’s important to always keep in mind is that they should not be regarded as definitive but rather as one contribution to a body of knowledge that can and should grow.
Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created. One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him. All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum. So, I decided to create my own.
This is the first increment. I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.
You can download it at this link: Meet: Scrum.
I’ve been giving out a cheat sheet on Scrum in my training classes for the last 6 years. It has evolved a great deal and I thought it would be timely to share it.
All of Scrum Diagram – OpenDocument Graphics
I also have a guidelines/rules-of-thumb list:
And some pitfalls listed out:
Scrum Product Owner Pitfalls – PDF
Hi Everyone! As you know, I’ve been working with my team at Berteig Consulting and with some of our clients to create the OpenAgile method. OpenAgile is based on Scrum and Lean, and integrates some important learning and teamwork principles and practices. We’ve just published the first draft of the OpenAgile Reference Sheet. This is based on the OpenAgile Primer as well as integrating some late-breaking learning about the use of Agile in non-software environments. I hope you like it, and let me know if you have any suggestions! We’re going to get to an official first release of OpenAgile soon, and when that happens, we will also be starting the official “open” part of it – OpenAgile is meant to be an open-source agile method!
http://pligg.scrum-on.com/ – Just found this through Niall O’Keeffe who is an attendee at my Certified ScrumMaster course.
This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices. Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt). I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses – if you want it in MS Office format, email me at mishkin@berteigconsulting.com). I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”. I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development. I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve. Perhaps it could be used in a retrospective setting. Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients. If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments. My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.
Agile Practices Adoption Worksheet (OpenOffice format – 68KB)
Having just finished a substantial series of articles on the Benefits of Agile, I thought it might be good to let you all know about some other ideas about these benefits. I don’t agree with everyone who has written on this topic, but of course, you can judge for yourself!
Continue reading Other Resources on the Benefits of Agile
