——————————————-
Top Ten Reasons to Update Your Task Cards
- The team would know every day where they stand with current sprint.
- Senior leadership could walk in any time and determine if the team is being successful for current sprint.
- It shows your individual progress to the team.
- You will feel confident and good about achieving or doing something as it’s documented.
- The rest of the team will feel the pressure to do the same.
- It empowers team to be competitive and successful.
- Mike Vizdos can make a cartoon out of task updating.
- The chickens would know the pigs are getting their work done.
- If David D. or John S. came back in the room, they would know we continue to use Agile processes
- It makes Marty and Venkat VERY happy!
Where Does Task Updating Show Up
- Daily Burn Down Chart.
- Factors into Product Burn Down Chart.
- Weekly Status Report.
- Weekly Updates to the PMO.
Who Sees Task Updating
- Anyone who walks into the room.
- Chickens.
- Senior Leaders like Ken A, Kathy K, & Patricia.
- Pigs.
——————————————-
So, do I agree with everything written in the list above? No, not really. However, I am thrilled to see people taking the time to help shape the community with submitting new ideas, so I did not edit the list(s) in any way.
In the spirit of “Yes… And….” (this is different than the people who say, “Yes…. But….)… I’d like to add a few more thoughts of my own…
On writing task cards and user stories, check out www.mountaingoatsoftware.com where Mike Cohn has written some incredible books and has some great information about how to use these artifacts more effectively.
One thing that is also good for keeping the tasks updated in a visible location is to make sure it gives context to the also present (we hope) burndown chart. If people see the burndown chart without information to back it, assumptions may possibly be made that are incorrect or invalid altogether.
OK… I’d like to hear more feedback from you if you are interested in providing it…
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
January 29, 2007
Just wanted to let you know that I have exactly 3.5 prime seats left for my Certified ScrumMaster Workshop in Richmond, Virginia on Monday and Tuesday next week (January 29-30). Fun will be had by all!
If you are interested please visit www.michaelvizdos.com/scrum for more information or go directly to www.michaelvizdos.com/enroll to sign up today!
If you cannot join me next week, I will be in Pittsburgh, PA and San Diego, CA soon.
And finally… If you are interested in a private session with your group — contact me directly.
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
January 25, 2007
This week, I am writing about something that shocked me the first time I saw it happen… then I became numb from seeing it so much.Now, I hope this article shocks me — and others — out of something that should never happen in on an Agile Team.
One of my colleagues once walked into a room with a new team. When he told me about it, he said something along the lines of, “It was so quiet you could hear the waterfall.”
Think about that last statement for a moment. I’ll stick around.
Welcome back. Good thought break? Hope so.
When *I* hear this statement, I realize a team is probably not working to its full potential. There can be many reasons for this.
The first reason, and obvious most of the time, is that a lot of people in our industry are introverts. For instance, I am an introvert. I have to actually *work* at talking to people and it does take a lot out of me when doing a workshop or meeting with a group of people. To recharge, I need quiet time alone. Other people I know are completely opposite… they are totally jazzed after doing a workshop or are completely comfortable when at a party working a room. They’d go crazy in silence.
So, how does this relate to an Agile Team Room?
Besides realizing the differences between introverts and extroverts, I also have realized that teams converting from waterfall methodologies (big up-front-designs) to working in a room with other people may need help making the transition.
When I see this as a serious problem — and I do — in new teams I work with, I work hard to actually settle in work with individuals to make little changes on a daily basis.
One person at a time.
This includes things like when scheduling a meeting within the room with the same team members… I work with people on the team to break out of the habit of scheduling something in Outlook (or other calendar systems) when it only impacts the members on the team. See… they are in the same room on a daily basis. If they are not…. influencing the breaking of this habit yields some great results.
So what do I do? After a standup in the morning, I try to facilitate team members to talk about when to “schedule” time to dive into details (usually discussed during the standup) using a white board or flip chart as their “new schedule”. This starts getting people talking. And working together.
Making it visible to all involved parties. You never know what can happen when people start talking in the room — and what others can actually contribute.
Usually after a few weeks people start realizing that they can actually do this on their own, throughout the day. Without “scheduling” meetings for internal meetings of the team members that are in the room together all day.
Sounds simple. But.
That is one of the hard habits to break on a team that is culturally adept at meetings to have meetings to have meetings (and so on).
The same ideas apply to the usage of Instant Messenger programs. I have sat and watched people in a room — a totally silent room — typing away “talking” to one another as they are sitting right with each other.
This is insane. But a regular occurrence.
As I see this happening, again I work with individuals in actually putting the two people together to talk. Using language skills instead of typing. Typing sucks as a way to communicate with each other… because I have read (and know this from experience) that 90% of all human interaction is by non-verbal cues. And, email or Instant Messenger cannot convey that.
Heck… This blog is one-way communication, with me trying to make assumptions that the reader (you!) understands what I am writing and how I really mean it. That is tough, especially since most of us have never met in person (nor we will ever).
So… if you see this happening on your team today — or in the future — work with individuals (one on one) to make small changes on a daily basis.
Doing this will result in a happier and more productive team. I promise.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
January 22, 2007
Hi all.
Thanks again for reading the blog and providing some awesome comments… please keep them coming!
I do not know if you have noticed, but at the bottom of every page published is a series of flags. I’d like to hear from you to see if they would be more valuable moving towards the top of the page…. but first, I need some people who actually READ those languages to check them out for me. So… If you can read one of the 13 languages this site is automagically translated into, please check out some of the links from the cartoon pages and let me know if they are even close to accurate — or a waste of time to upkeep on my end. I use an auto-translator service, but I want to know if it is worth continuing!
Please check it out and let me know.
Thank you!
- mike vizdos
mjv@michaelvizdos.com
Resources include money and budgetary stuff. While I usually say that people are NOT resources, in the end this is where people “fit” in this example.
Schedule is the time you have to deliver on a project.
Scope includes the features and functionality of the deliverables you will be providing to the end user.
Scott Ambler has written about how this triangle is really “broken” today, and you can read more about it here. There is some good information there and much can be learned from it.
Today I will focus on what is considered the only movable line within Scrum, and that is Scope. Why?
From a Resource perspective, each Sprint normally has a fixed amount of people and equipment. You can easily predict the burn rate for a Sprint.
From a Time perspective, each Sprint is normally a fixed length of time (anywhere from a week to a month, depending on the team norms).
So, that leaves Scope as the one item open for discussion during a Sprint. Let me explain further…
The Product Backlog contains all of the features and functions that the Product Owner has identified (with the team) as the highest priority items to deliver for the overall project. Following each Sprint Review and Retrospective, the team gets together during the Sprint Planning Meeting to discuss the latest Product Backlog and decides what items should be pulled into the next Sprint.
Once the team — along with the Product Owner — decides what to pull into a Sprint Backlog, the Product Backlog then becomes part of the background noise in a project. Once a Sprint gets started, the team focuses on the Sprint Backlog while the Product Owner — and other outside stake holders (Chickens) — can play with the Product Backlog to their hearts content. Outside the team room. Responsibly (remember that… do not do things blindly or irresponsibly!).
So, the team gets started with their Sprint and is chugging along.
The Scope is fixed. The Resources are fixed. The Time is fixed — and ticking away. All is well until about mid-way into the Sprint when….
“Uh-Oh Mike… I see from the Burn Down Chart that we are not gonna make it!”
What should the team do?
Panic?
Uh. No.
This is actually something that is normal (and, by the way, CAN happen in reverse (as in… “Mike, we have some bandwidth…”).
And either way… this is actually a healthy thing if you work it the right way.
The WRONG way is for Chickens to come parachuting in (because that is what they love doing) and offering to “help” by adding what….
RESOURCES or trying to EXTEND the Sprint TIME.
Remember… on Resources… nobody can make a baby in a month by adding eight more women. Really. And time… well… that is fixed; as much as we want more hours in the day.We will end the Sprint when we will end the Sprint. And be done.
So… that leaves the Scope. Here is what should occur….
The team should sit down and have a facilitated discussion with the Product Owner about what is happening (this should not be a surprise for an active Product Owner) and why the Scope needs to be adjusted.
If the Product Owner is truly empowered by the outside stakeholders to make a decision, the Product Owner can then take user stories and tasks OUT OF SCOPE for the Sprint and add it back to the Product Backlog to be re-prioritized for a future Sprint.
Is this hard?
Sometimes.
OK. Most of the time.
Is this reality?
Yes. And that is why Scrum is set up to deliver working software at regular time intervals using fixed Resources and Time throughout a Sprint.
Should you follow this advice blindly?
No.
Be responsible. Think. Really.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
January 15, 2007More:
December 13, 2006
Older Articles »
