|
|
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
And, it works.
So, here is a quick lesson on budgeting on a Scrum Project.
And no, you do not need any super computers or fancy software models.
Got an abacus?
Good enough!
Remember if you will the idea of the iron triangle. If you are not familiar with this concept, please visit the link and come back. I will wait for you!
Welcome back (smile).
In Scrum, your timeline is fixed (either called a Sprint or Iteration). For the purposes of this example let’s state the Sprint length is the classic 4 weeks.
In Scrum, you have pretty fixed resources (some people call them people, and not resources [I agree!]). For the purposes of this example let’s say you have 10 people on the team. And, again, for the sake of easier math (on me right now!), let’s say the bill rate is 100.00 per hour per team member.
So here comes the budgeting!
Take your team members ($1,000.00 per hour (wow!)) and multiply it by 8 hours ($8,000.00 per day ) * 20 billable days = $160,000.00 per Sprint.
If your project involves a lot of infrastructure or software licenses or bla bla bla… count that in now.
However…. there… you have the burn rate for the team. About forty grand a week.
And. This is pretty accurate.
Within 3-5% on a personal basis. At the END of real projects.
Keep it that simple.
Really.
And then.
DO NOT fall for the trap of starting to associate the burn rate with story points.
“Why not Mike,” you may be asking yourself?
Well… think about the classic “result” that managers (Chickens) try to associate in their minds….
“Let’s see. Doing the math, we can get 3.47 points per person per Sprint. Let’s ADD people to get that number up to 4 points per Sprint and I will look like the hero!”
Warning lights and loud sounds should go off in your head if you start hearing this silly reasoning.
Why?
Because, as we ALL know (Pigs)….
Adding people to projects (especially ones that are “in trouble” never helps — especially in the short term. In fact, this is usually a major drain on the current team and the velocity starts trending downward.
Yikes.
Unfortunately, I have seen this false reasoning applied time and time again. Even after coaching managers (Chickens) who really do know better.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
April 30, 2007
The Cast of ImplementingScrum. Infamous Yet?
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
Without further ado, I present to you the cast and characters of the site www.implementingscrum.com. Think I missed something or need things to be added? Please let me know!
Otherwise, please enjoy and drive responsibly….

Scrum Master
Our intrepid Scrum Master is very passionate about his work. Scrum is not just “work” to him — it is a way of life. While gentle and thoughtful most of the time, he has his moments and gets on his soap-box every once in a while. In life outside of being a trainer, he has a wife and family, a dog, and 3.14784845 other various pets (on average). He also is a Certified Scrum Trainer and loves traveling the world spreading his larger mistakes (which, by the way, sometimes teach you the most). He is very introverted and an ex-command-and-control-a-holic.

Chicken
This is your typical stakeholder. If there is such a thing. Others may see the Chicken as their manager (we may add a character to the cast in the future if the Chicken Role needs a specific stand-in). Either way, Chicken does really try to “get it” and is continually looking to learn to improve. And, most of the time, the Chicken takes things out of context and winds up getting the Pig in some type of trouble in the future by their collective actions. Chicken is single (spends a lot of time on the net and playing World of WarCraft and searching for Jessica Alba pictures) and is always looking for other available Chickens who have not had their heads cut-off just yet.

Pig
The Pig in this series is a hard working team member. With real life issues at stake. Unfortunately, as true many times in life, the Pig winds up taking the fall (or blame) when things go horribly wrong. Yet the Pig stays with it. And gets results. Pig is a widow and lost its mate on a trip to the Dole Pineapple Farm during a VIP Pig Roast in Hawaii; no further comments can be made on this impending action. One other fact — since inheriting the insurance money, Pig REALLY does not have to actually “work” for a living. Hmmm…. will it one day walk out, or continue to stay and learn — or teach — as the case may be?

Product Owner
The Product Owner does a great job shielding the team from the outside noise of what the team needs to get done on a daily basis. Is this the right person for the role? This is something teams continually must address with the person in that role. When originally casting for this position, I had a super-hot model-type in mind; however, as with all casting calls, it wound up that this Product Owner REALLY was the right person for the role (OK… so in reality Tony (the illustrator) voted against this — something I will have to thank him for someday!). Semi-clueless on life (we actually do not know anything about his life outside of work at this point in time); however, this Product Owner understands his business like nobody else we know… which makes him an awesome Product Owner. And he knows that working with all the outside stakeholders on a project sucks (in real life too sometimes!); however, the team respects him and looks to him for priortization of the Product Backlog and being collocated with the team throughout the day to answer any questions they may have. See — he really is awesome!

Ken
Every methodology, framework, or process [whatever you want to “call” Scrum] needs a thought-leader. The other characters look to him occasionally for his “by the book” answers. All in fun, of course. And please do not ask me if the man wears black turtle necks to bed… you will have to ask his wife that one (smile… because you see, I have never had a “Ken Sighting” without him in his trademarked black turtleneck top).

Scott
His name is Scott Ambler and he has been one of my personal mentors for many years. We co-wrote a book a few years ago and have traveled to some pretty cool places on the globe over the years. In addition to Scott being a friend and mentor, he has also published about 20 books (either as author or co-author) and now, as he likes to say, “IBM joined me.” He now works for IBM as an Agile Practice Lead (pretty cool job I think) and we still keep in touch. His profile can be found at www.ambysoft.com/scottAmbler.html.
So why have I included him as a character on this site? He knows a lot about various different agile methodologies. In fact, he is the leader in the industry on a lot of them (because like Ken Schwaber, Scott Ambler has helped get the word out about different agile software development methods.
And.
He is a bit on the controversial side. For instance, he is not a big fan of the current certification model that I (and others) teach; this should add some good content for the cartoons (smile). Sorta like I approach things in life. Coincidence? Hmmm.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
April 23, 2007
Updated:
January 7, 2008
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
Today, I discuss ways in which the Product Owner interacts outside the team — with what I call, “The Noise.”
First, please remember that each Scrum Team should have ONE Product Owner.
ONE.
Not two.
Not three.
Not a committee.
ONE.
Comprende?
This is a super important concept to understand and make sure you are actually following on your Scrum Team. It is a major point of failure when implementing Scrum if your team is being run by a committee of Product Owners. If you are in this situation, I think you know this in your heart; and, you probably feel the pain on a daily basis.
For the reminder of this discussion, lets assume that you have one Product Owner.
Ahhh. Nice (smile).
This Product Owner is actively involved on a daily basis with the team. In fact, as a team member, you feel like the Product Owner IS a part of team. This person attends the daily stand-up meetings, is actively involved in your Scrum Team Room (collocated of course), and has the answers and is empowered by his or her peers and bosses to make the call on direction. If there are any questions, this person knows how to navigate “the system” outside of the room, and is able to get the Scrum Team a definitive “yes” or “no” (or answer) in a timely fashion.
Sounds easy, right?
Here is what could be happening outside the room. And this is where the Product Owner really needs to shine for the team.
On the “outside” world (away from your Scrum Team), the Product Owner is actively defending people from coming into your Scrum Team Room and asking for new things to be added. You know… those pesky Vice Presidents who have “friends” on the team that can do “favors” for them. An effective Product Owner — in conjunction with the Scrum Master — works to ensure this actually stops happening.
This is part of shielding the team from “The Noise” on the outside world.
In addition to being a shield for that, the Product Owner has the distinct opportunity to help all the outside stakeholders shape and form the Product Backlog (remember… there is a difference between a Product Backlog and Sprint Backlog ). At the end of every day (or minute, depending on how your organization looks and reacts), ultimately it is the Product Owner who is the single wringable neck (a term, by the way, which I hate to see used gulp). This person has the responsibility of making sure the priorities are negotiated and are correctly identifying the highest risks to the organization today.
This can be tough.
The Product Owner must negotiate with his or her peers and up the chain of command in an organization (even if it is an organization where there is only one more person with an opinion above the Product Owner).
And remember, like you (o Scrum Team Member), this person cannot just make stuff up in a vacuum. If that happens, I can pretty much guarantee career suicide for that person. I have, unfortunately, seen that happen.
So.
If you are on a Scrum Team today and things look rosy and things are going smooth, be thankful.
If your Product Owner makes it look easy to the team, you are lucky.
Hmmm…
If you are not in the happy happy situation as described above, maybe it is time to chat with your Scrum Master, Product Owner, and Team (maybe a Retrospective Topic???) about what can be done. Call in someone from the outside if needed (shameless plug for me if you take it that way!).
If you are in the happy happy situation as described above, then give your Product Owner a hug (or at least a sincere “Thank You” if it is inappropriate) right this moment. Allow that person to continue shielding you from “The Noise.”
And, continue making your team even higher performing than it started today.
Good luck!
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
April 16, 2007
This is The Podcast — the first one on www.implementingscrum.com — based on the blog entry and comic from this past Monday.
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
And no, I am not going to tell Scrum Teams to “just ignore it, and it will go away.”
But I am going to challenge the system. At least a little bit (smile).
Before delving into this further.
Think about the importance of customers.
Really think about this.
Not “IT” versus “Business” or whatever you call it internally… but REAL customers who PAY your company REAL money.
In the beginning, as either an entrepreneur, recent university graduate, or single person…. you were accountable to basically you. And oh, the IRS (or whoever collects taxes). And maybe a puppy. When you delivered services you were paid.
Then…
You started growing. Your company added people. You were responsible for payroll — making sure your employees received a regular paycheck; and it had to clear. Or you got married (or had a civil union if it is legal where you live). Your puppy starting growing up.
Then, one day, you decided to take the company public. Or have kids. Your puppy turned into an adult dog.
All of the sudden, you look for your customer — remember, the people that actually PAY you for services rendered — and see that now you have a lot of oversight.
From “stake holders.” Be it the IRS, your board of directors, your shareholders, your clients, you internal teams, bla bla bla.
Where the hell did your customers go in all of this. Remember…. little Joe (or Jane) customer who actually pays the bills for all this new overhead? Hmmm… people lost sight.
Empires started to grow.
People — not resources (smile John) — that are paid (ultimately by a customer who uses your services and could give a rats ass about what happens behind the scenes) start building empires. And this is not just with public companies (sad, but true, and I have been there).
One of the many empires that emerge is something called “Compliance.”
There job is to create and publish policies, procedures, standards, guidelines…. bla bla bla. Your customers (who pay you) do not care.
Ah.
But another empire — the auditors — who compliance can then “blame” start making sure you are following ALL of the darn things that they (compliance) created.
This, my dear reader, is the agile police.
And, breath here….
It is a cost of doing business.
That being said, remember that you can be 100% compliant. And have no customers. Then what?
But… until that message gets across within your organization, here are a few tips:
1) Become compliant.
2) Stay compliant.
3) Work with compliance.
4) THEN… start questioning compliance.
I know. I know.
Compliance is important.
Very important.
Is it worth going out of business to be “compliant”?
I will leave you with this.
For now.
Gotta run…
Oh…. want to hear the Podcast of this entry? Click The Podcast.
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
April 9, 2007
Hi all,
As we move into April (wow, the year is flying by), I’d like to ask for your feedback on the site/blog and find out — from you — what I can do to make it a better experience going forward.
Some specific questions I am wondering about include:
- Is anyone interested in posting some advertising on the site? If you know of anyone who is (or if you are in the position to do this), please contact me we can work something out together I am sure. One of the reasons I am asking is because it looks like I will need to get a dedicated server (and increased bandwidth) for the site in the near future, and asking the community for ideas to fund this was my first thought. We are getting a ton of traffic and it is almost doubling on a monthly basis (thank you!). The site is currently hosted on a shared server and I am blowing over the current allotment of bandwidth already.
- One of the areas I have not touched yet is with podcasting. I know this is a hot topic and wanted to know if anyone would *really* be interested in either hearing a weekly broadcast about the comic/blog and/or if anyone out there would be interested in doing a “seven minute conversation about Scrum” (OK… crappy title and we can work on it); this would basically be me interviewing people in the trenches on a weekly basis to find out what problems, issues, or impediments they are having while implementing Scrum. I know that people reading (and maybe listening) can learn a lot about this from others, and I am more than willing to start this if you are interested. We can keep it as confidential as you’d like!
- Translations. As you may have noticed, the comic strips are starting to get translated into local languages. If you are interested in assisting with this, please let me know and I will work with you to make this happen. The only compensation is “credit” to your name but it is always fun seeing them in lights (isn’t it?).
- Ideas for cartoons. Always welcome. And again, I will credit you however you’d like. Love to hear about real-life things that happen other than on teams that I work with!
OK.
That’s all for now.
I do appreciate your continued support both reading and helping me spread the word about this blog to people around the world. It is truly awesome to see it makes a positive impact (most of the time). It’s been a fun six month start so far, and hang on for more fun as we continue the journey together. Stick with me!
Thank you,
- mike
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
The topic for this week is regarding dysfunctional scrum (or stand-up) meetings.
Here is the way they “should” work:
The team stands up and faces one another. Sometimes this is a circle, sometimes it is a square. It does not matter… people should stand up.
Chickens cannot talk during this fifteen minute meeting. Yes. This should not last more than fifteen minutes.
Each person on the Scrum Team takes their turn answering the three questions, which can include:
1) What have I completed since the last meeting?
2) What will I complete before the next meeting?
3) What is in my way (impediments)?
Yes, the nuances of how the questions are asked can be a little different, but sticking to answering the three questions is key. The Scrum Police will not come after you if you do not ask the questions specifically as they have been listed above (for example, “completed” can be replaced with “done” or whatever).
The key thing that this daily meeting is set up to do is so that each team member can communicate with the rest of the team on what they are doing and what they need help with.
Here is where I have seen these meetings go bad….
- The meeting lasts for an hour. And nobody seems to care.
- People talk about things that are not related to the three questions.
- Team members try to solve problems.
- Chickens speak.
- People sit.
- Cell phones on. Laptops open. People “checked out.”
- People show up late, or do not even bother to show up.
- Status reporting to the Scrum Master.
I will address each of these topics in a little more detail.
Is it an exhaustive list?
No.
Is it in any specific order?
No.
However, if you see some of these topics popping up when you are working day-to-day, maybe it’s time to figure out — as a team — what can be done to fix things.
- The meeting lasts for an hour. And nobody seems to care.
Apathy sucks. If your team is having diareah of the mouth and the stand-up is lasting more than fifteen minutes, the Scrum Master needs to keep the team focused on answering the three questions.
And move on.
- People talk about things that are not related to the three questions.
This topic feeds into the problem of the daily meeting going more than fifteen minutes. Yes, it is great that you are spending time outside the room on other things (even “life”); however, the purpose of this meeting is to answer the three questions and get coordinated.
You will have time during the remainder of the day (hey… you are collocated… correct?) to talk about that other stuff.
- Team members try to solve problems.
Ug. This is something I see from both new and experienced teams. If there is a problem (and, there usually are) that the team needs to solve, put it up on a board or list someplace visible in the team room and make sure people work on it and solve it during the workday.
- Chickens speak.
Enough said? If Chickens want to speak, they can speak AFTER the daily meeting.
- People sit.
Stand up. OK, unless you physically cannot do that.
It will help keep the meetings short.
And, it helps team members avoid the next topic….
- Cell phones on. Laptops open. People “checked out.”
Oye. Ug. Ouch. Scrum Master — help the team come up with norms that help the teams get over this. It is a good topic for a retrospective (to be written about soon, I promise!).
- People show up late, or do not even bother to show up.
OK. Scrum “says” people should pay a penalty if they are a member of the team and they do not show up for a daily meeting. There are a ton of excuses, and people can get creative (like for instance… I have an “emergency” (wink) is used as a “valid” excuse to miss them).
Missing a daily meeting has an impact on the team.
Your team.
One that you are a part of!
Some of the penalities I have seen over the years include paying a dollar (or a LOT more), eating a pickle (one of those big disgusting ones out of a large jar — at 9:00 in the morning blech), wearing a hat, receiving a Scrum Witch, or… or…. or….
Penalties can get creative (as I have learned).
But.
Show up. Avoid the silly penalties and excuses and be there for your team.
- Status reporting to the Scrum Master
This is a classic pattern I see for teams converting from old waterfall approaches (with a command and control Project Manager) to agile approaches of doing work.
There is no role of “Project Manager” in Scrum.
For a reason.
The Scrum Master is not a Project Manager in the classical sense.
So Scrum Team members… PLEASE do not give daily status reports to the Scrum Master.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
April 2, 2007
Wow!
The cartoon of “The Classic Story of the Pig and Chicken” is now translated into Italian, Polish, Portuguese (Brazil), and Russian (just over the past few days).
That brings the total number of translations up to seven for this one cartoon.
Check them out here.
If you are interested in helping with any other translations (they do not just need to be the Pig and Chicken cartoon), please contact me!
Thank you,
- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com


