Quote Series Part 7 - Philosophy (contd.)

This is part eight of the series, to see what this series is about, click here. This is the last in this series.

Quotes on "Philosophy"

Make time to make it right, or be prepared to do it again - Denise Caron

Embrace new directions... not everything you do will be used, sometimes, the target changes. Re-aim and move on! - Denise Caron

Change is constant... don't fight it, leverage it. - Denise Caron

Don't fall in love with your product, someone will be there to change it, it's a promise. - Denise Caron

Blindly following rules is a fools errand. We have enough grey matter to discern when the rules are helpful and when they are not. We have the responsibility to continuously measure whether the rules are helpful, or whether they are not. - Uncle Bob Martin

It is solely and utterly the team’s responsibility to figure out what to do, and to do it. - Ken Schwaber

"Better" is typically a word leveraged by those in control (eyes of the speaker). "Appropriate" is typically a word referencing those affected (surrounding group). We should seek that which is appropriate, not that which is better. Avoid elitism, blanket statements, or viewpoints of limited individual experience. - Kevin E. Schlabach

Without prioritization, nothing is a priority. - unknown

The practices are not the knowing: they are a path to the knowing. - Ron Jeffries

To tolerate a problem is to insist on it. - Ron Jeffries

If it hurts, do it more often - Martin Fowler

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Quote Series Part 7 - Philosophy

This is part seven of the series, to see what this series is about, click here.

Quotes on "Philosophy"

...initiating requires a willingness to look foolish, stupid, or uninformed. To initiate great things, you must truly not give a damn about what people think about you. - Seth Godin (Tribes book)

what you call things and their meaning matters cuz it sticks in people's mind - Twitterstream from Lean Kanban 2009 conference

No good idea can be judged by the number of people that get it - Ron Jeffries

Learning faster than our competitor is our only sustainable competitive advantage. - Denise Caron

Change happens fast, our competitors will not wait for us to get ready. - Denise Caron

Self-organize... don't wait to be told, be accountable and stride forward. Self correct! - Denise Caron

Satisfaction comes from closure- open-ended tasks can't be closed - ObjectMentor coach

Managing the project is MANAGEMENT'S responsibility... do the best you can with what you know now and program as though you have time to do a good job. - ObjectMentor coach

If you deliver every day, then no deadlines are special (or scary). - ObjectMentor coach

If it doesn’t hurt, then you’re probably not changing enough. - J. B. Rainsberger

If you just do the same things, only faster, then you’re missing the point. - J. B. Rainsberger

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Quote Series Part 6 - People

This is part six of the series, to see what this series is about, click here.

Quotes on "People"

If you don't make mistakes, you are not working on hard enough problems - Frank Wilczek

Open yourself to critics and take your capabilities to new heights. - Denise Caron

If you goof, apologize. If you apologize, mean it. - Seth Godin

If you want something to happen your way, try asking instead of demanding. - Seth Godin

If you’re getting feedback, realize that the person must care a lot to have sent it. - Seth Godin

Anyone who uses the term “resource” when referencing people has to put $1 in the “inappropriate comment” jar! - unknown

No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today. - Kent Beck

A tool is nothing without a skilled artisan to handle it. - unknown

Don't inflict change on people. - J.B. Rainsberger

A dead scrum master is no good to anyone. - unknown

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Quote Series Part 4 - Metrics & Managers

This is part four of the series, to see what this series is about, click here.

Quotes on "Metrics"

Another purpose of measuring capacity is to improve throughput. If you plan for less than your capacity, you get less done than you could have. If you plan for more than your capacity, you get less done than you could have.

Having a plan with "enough" work in it less some slack to improve the probability of meeting commitments increases the amount of work that gets done compared to planning for too much or too little. - Kent Beck

Once you start measuring something, you can easily end up in a situation where the measurement itself starts influencing the things you want to measure. - unknown

Quotes on "Managers"

Management owns the 4 T's (time, talent , treasury, target )... everything else is up to the team. If you have a issue that affects one of the T's, then ask management for input. - Tim Ottinger

Message to Management - eventually, you can push too much change at once.... back off and let the team normalize. - JB Rainsberger

In my experience, it is the leader’s (manager’s) job to intervene in the case of inappropriate behavior, and when he or she does, the rest of the team will be grateful for the intervention. It is being a “servant” to the whole team by suppressing the individual behavior that will keep the team from being successful.

It’s not about telling people what they are doing wrong. It’s about constantly steering everyone on the team in the direction of success, and never letting any individual compromise the progress of the team toward success. - Mary Poppendieck

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Managers are not Super-You's...

Nancy McCall wrote an interesting post about somebody's thought that “Your boss should do your job better than you.”

Her points were:

- Managing people requires different set of skills than developing software, or whatever the job is of the group being managed.
- Proficiency in any area is worthy of respect, regardless of whether is it your area.
- It is not all about you.

She goes into further detail, feel free to read the full post.

I commented further:

Agree. I’ve modeled my management career path after those managers that were best at enabling their team to do something great with their collective powers. This typically meant that the team was collectively much smarter than the manager, but it was the manager that helped them get there.

If I had to be a better coder than the people I help manage, I’d be out of work. Instead, I’m a valued person in my organization because I can do things they can’t… and they come much more naturally for me than for them.

Post agile, one third of you will be gone...

About 6 years ago, I was at a company going agile... I didn't know much about it yet. I didn't realize how it was going to affect me and my career path. I had no idea that it would invigorate me and show me a better way. But there was one thing I heard immediately that I did understand, and it excited me.

The head of the division stood in front of 3,000 employees and stated

"... and after we are done going agile, I won't be surprised if one third of you will be gone."

You could have heard a pin drop. I rarely hear deafening silence, but I heard it that day.

He went on to explain...

"...some of you are managers. You are not the type of managers we will need. Some of you are employees, you won't be comfortable working this way. The pressure will go up, but the motivation and reward will also."

And finally...

"This is okay. It is where we are going. We are committed to it. I accept that this will happen and am respecting you enough to say it right now. Many of you worked hard to help us get to here, but that doesn't mean it will continue to be a good home for you."

(disclaimer: for those who were there with me that day, I know these weren't the exact words... but they were the message!)

9 months later I remembered that statement and I glanced around. I realized I was working with different people. I was on an awesome team. The team I was on before was really good, but they were all like me... the same role. Now I was on a team with really smart hard-working people that weren't like me. We were all different roles and we all have to think and work together to be successful. It WAS harder, but it was ALSO more fun.

And yes, we lost a lot of people. The people that just wanted to tell other people what to do were gone. They either left or were removed. The people who liked sitting in cubes and being told what to do left also.

This is why my first agile experience was so revolutionary. I doubt many of you had such a hard immersion through the transition, but it was wonderful!

The question is, who was left on the sidelines through all of that? Mike Cottmeyer wrote a good piece on this yesterday. How do those remaining managers adapt?

Does a SM have to be technical?

Kyle Smith asked the following question in the Agile Coaching LinkedIn group:

Often job postings prioritize extertise in a specific technology over attributes defined by Agile. Can a CSM succeed w/o being a subject matter expert for a particular technology or industry?

Keith Sterling responded with:

I don't think you need to be a subject matter expert, but I personally believe you have to have some level of understanding of the technology involved, otherwise you will find facilitation extremely difficult.
As a scrum master people will be looking for you for guideance, when you are planning and cutting tasks its important that you atleast know what the team is talking about and why tasks and plans are being proposed in a specific way.

Scott Duncan made several good points including this one:

Sometimes, skill-specific requirements are there because the org's culture will not "respect" someone in a more "mgt" or consultative position without low-level tech'l skills regardless of the fact that the role will not require them to actually use those skills.

My points were the following:

It depends on the team. Without getting into a debate of which is academically better (though I have an opinion), I see two types of agile teams...

1- a team of developers
2- a blended team of roles including dev, analyst, test, usability, etc

In option 1, it is important. You need to speak the language of the team since the team is speaking tech and you need to be the translator to the business.

In option 2, it is not. The team is a holistic group, let the tech folks speak towards business goals and value. Everyone should be focused on what is being delivered in business terms. The non-tech folks need to understand tech and vice versa. In this scenario, the CSM needs to be in between the knowledge of the tech and non-tech groups.

I haven't coded in 7+ years, but I leverage my computer science background to bridge the gap. I'm more effective due to my tech background, but I hardly ever have expertise in the specific language/tools. I have had success without being an SME of the particular technology.

It should be interesting to see if anyone takes the counter point of view.

Can Agile Teams Recognize an Individual?

So, I found myself in an interesting debate with KanbanJedi. He raised a really good point that I agreed with:

... So recently I heard of a team that is using Scrum and their manager had decided to have a “Person of the Iteration” award for the person that completes the most points in a Iteration.

I think this totally misses the point of Agile being a team of people working together to get as much stuff “done” in an iteration to the highest levels of quality...

... What happens if several people work together on a story – who gets the credit? Well firstly you’re not encouraged to do this to win the award and secondly I have no idea how that works.

Fundamentally, I believe that he and I agree that any award that encourages individual behavior over the team will be destructive to the self-empowered self-managed team structure. I took a minute though to play devil's advocate and see if there was an example of individual recognition that could grow the team in a positive way.

My first thought was that it had to be from the team, not from a manager or due to a metric.

My proposal was MVP, or Most Valuable Pair Partner:

I’m thinking of a mature agile team that does TDD and pairing (that already limits this enough to strike it down from being a public idea since most teams aren’t there).

If every person on the team nominated the peer who provided them the most value that sprint as a pair partner, then the team is selecting the person who most contributed to selflessly supporting others in delivering value/velocity and/or mentoring/knowledge sharing. Such an award would encourage people to not work as individuals, but work to uplift the team as a whole.

As nice as this sounds, I'm inclined to agree with KanbanJedi that this might be a bad idea. Only a very mature team can handle such an approach and not let it degrade into someone gaming the system for recognition sake. I guess the award could be recognition only (pat on the back) so that it's about pride and nothing more, but there is a risk.

So, the question is whether an agile team can provide individual recognition to a team member? Or is it too filled with risk to even open this pandora's box? Does this fit into Mary Poppendieck's points on constant and timely feedback, or is it a bastardized version of the old management's way of passive-aggressive team-destroying motivation.

Thoughts?

Flashlight vs. Laser...

Peter Stevens has been talking about his journey from a PHB to a scrum master (and agile coach). His recent presentation included some interesting lessons, journey notes, and advice.

One of the things I'd like to call out is his metaphor for an agile (scrum) team before and after the transition (slide 17 of his presentation):

What is the difference between ordinary light and a laser?

A bulb produces white light – the light is at multiple frequencies, going in all directions and produces more heat than light.

Laser – the light is all on the same frequency going in the exactly the same direction. A laser pen can illuminate a point across the room by daylight. A laser can read bits on a DVD. A laser can measure the distance to the moon (which is increasing by 38mm / year).

A group is a light bulb – bright individuals, but individuals going in different directions

A team is a laser. Focused, synchronized, with incredible potential.

If you do Scrum, you can turn your groups into genuine teams.

I love this metaphor! It's a good one. Having said that...

We have to be careful about perception. I know managers that prefer the flashlight. Instead of rapidly focusing the laser on one or two things at a time to quickly and efficiently "kill" them, they'd rather shine a bright light on the whole room and see what scatters.

It's a "let's do a little bit of everything and see what sticks" approach. Granted, this probably shows some flaws in strategy and vision, but it is a culture nonetheless... and it works for some people/businesses.

So... how do we tackle this issue? How do we make the argument?

Well... make sure your laser is effective. Make sure it can be redirected quickly. Make sure it can kill flies, not just gnats. Turn it into a Star Wars program. Make it a better approach than the stadium lights one.

(I didn't really say anything but fluff, did I? Fine, I don't have the answer... I'm just making a point an sharing frustration.)

Your ideas?

New manifesto...

If you haven't heard the buzz, a new manifesto was created and signed over the weekend. No, not a new agile manifesto, but a complementary one.

Instead of repeating others, I will joint point to them:

• the Manifesto for Software Craftsmanship itself
• Uncle Bob's announcement
• Aaron Weiker's blog post
• Fail Fast's post
• Jim McDonald's post
• Added 3/12: InfoQ post
  
• and I got several emails over the weekend so I know there will be more!
  

RP: 10 activities of PO

Repost: From Jack Milunsky on the ASD blog, post about the 10 activities of a Product Owner. Bullets summarized here, read full post for details.

1. create/maintain product backlog
2. prioritizes backlog
3. assists with epics->story breakdown
4. conveys sprint/release goals
5. represents, interfaces, engages customer
6. participates in standing and sprint meetings
7. accepts/rejects sprint deliverables
8. can redirect team/project with each sprint
9. communicates status externally
10. can terminate sprint early if drastic change is needed

Permission is not needed!

Over the last few years momentum has increased around the agile movement. It goes by many names (Scrum, XP, Lean...) but they are basically pointing at the same core inspiration: allow the team to be part of the decision making, quality, and accountability chain.

Typically people on the bottom have felt abused by the old system and latch onto this new system. Some test it successfully, and others yearn for more time to learn. Either way, the secret eventually escapes about their activities.

And then the dirty question rises: How do we convince the business to let us keep doing this great thing that increases our morale, quality, and predictability but is not easily quantified in the old world of thinking.

This is where I get confused. Since when did developers lower themselves to a blue collar status. Your job isn't to punch widgets, or flip burgers and assume that every break is clocked and pre-approved. We are a college educated group of people that bring a disciplined skill to our environment. Nobody asks the artist to make the artwork in half the time... only the artist can dictate how long it will take to do their work. Why are developers different?

Alan Cooper's keynote at Agile 2008 spent a lot of time talking about how the software process is more like a trade or craft than an engineering process that can be tuned like a factory. This was his foundation to explaining why usability needs to be incorporated. Here's an expert telling us..."Own your work!"

Then one day later, Uncle Bob presented a keynote that clearly stated the same point again... "Own your work!" His initial summary was craftsmanship over crap and led to a standing ovation of 2000 people which are all leaders in the agile movement.

Today, Tim Ottinger talks about fear of refactoring, TDD, and doing it right and tries to answer the question yet again. He also reposted from the XP mailing list a quote from Jame Grenning :

There are two values to software
1) Business value delivered
2) Ease at which the next important feature can be delivered

There is a theme here folks... quit asking for permission and own your work.

I've always struggled with the existence of the permission question for two reasons:

1. I started my career as a developer with a computer science degree and feel I can relate to the issues developers are going through today (though it has been 8 years since I wrote any real code)
2. I spent more than 5 years as a usability engineer. This role forced me to constantly justify the time and science behind this craft to insure I was allowed to do my job correctly. I was fighting against the mentality of developers that user interfaces had to be built with intention and to the business that this process was cheaper than not doing it.

So, I've always had to defend my craft. I've always had to sell my worth. And because of it, I've been successful at reaching my career goals.

Once again, I find myself pointing to the keyboard and saying get back to work and do your job the way you know you need to. Stop letting them make you compromise so much. Prove to them why you are so valuable and stop marching according to their defined instruction. Be the expert at how to do your job and manage your craft!

Now, go forth and quit asking this silly question.

Note: before you take my advice, become a maverick , and get yourself fired you should probably read J.B. Rainsberger's paper from Agile 2007 about "My Greatest Misses: XP"

Don't work for jerks 2...

One of the reasons people pursue agile approaches is due to the culture that is found within it. Instead of treating people like resources (cattle), we treat them as trusted team mates. Instead of focusing on a waterfall GANTT chart and controlling impossible things, we focus on communicating with the customer and setting realistic expectations.

This is reflected in the agile manifesto.

It is reflected in Norm Kerth's directive about retrospectives:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

It is reflected in Seth Godin's comments about not working for jerks, and Lynne Ralston's things to look for (prior blog post).

But I have come up with my own list. I like it and I wanted to share. So here is Kevin E. Schlabach's work environment directive-

A good work environment is a place where:

• everyone knows that we are all fairly compensated (removing distraction and providing stability)
• my peers and I share a pride in our work and take accountability for what we deliver
  
• our teams are respected and empowered (education and training is accessible, impediments are removed, feedback is responded to, there is a low level of politics/process/red tape)

allowing me and my team members to focus on:

• helping the company make money (profit, not revenue)
• keeping the customer exceptionally satisified (insuring long term viability)
• creating business value for the users (sometimes different than happy customers)
• staying prepared for the future (long-term sustainability, not short term money)
  

A good work environment is NOT a place where:

• people work through checklists of tasks
  
• meet the minimum requirements of their job
  
• are compensated unfairly
  
• therefore forcing them to constantly be on the lookout for better opportunities or ways to get ahead of their peers

What are your thoughts? Do you have your own version of this?

Agile Adoption Patterns...

Mike asks "Do you start with agile project structure or agile culture?"

My words on the topic:

Some companies already have an agile culture, many don't. I don't think you can create it out of thin air. If you are lucky to already have it, then jump into agile with both feet. Otherwise...

I like to use retrospectives first to build trust. Build trust by having the team raise issues and showing that the leaders will solve them. Then I like to apply stand-ups... show peer accountability and allow people to admit mistakes. These two things will catch the attention of upper management with happier, more productive teams.

This is the point where I jump to the agile process and structure. Sell your concepts, get buy-in, and start solving problems from the top down. Apply patterns to issues and gain credibility. People will start taking on this agile culture as they see it working.

His follow-up:

I think it boils down to this... you have to have culture, structure, and the necessary support from leadership to align business processes (HR, accounting, contract management, etc.) with development.

Click through to read the full post and what others have commented.

What type of leader are you?

Mike Cottmeyer talks about how "Project Managers, Agile Project Managers, and ScrumMasters tend to fall into one of three camps... ...The Tracker, The Remover, and The Anticipator".

It's a really good post about how the value of a leader is in shifting from helping a team overcome problems and keeping them focused on work to helping the team predict and remove problems before they happen.

My comment is that we can't expect a new leader to immediately be an anticipator, but they need time to assess the culture and understand the domain first.