It's coming! (Agile 2010)

You can find my presentation summary here.

Startups are agile by their nature?

Yesterday I had the privilege of presenting the topic of Agile to the portfolio of new companies being mentored by a company called DreamIt Ventures in center city Philadelphia. It's a great program, and I'm proud to have taken some time to support it. I'm sure that some of these smart folks will be successful.

The interesting thing I noticed when walking through their space was how they worked. Each "company" was a group of 2-4 people sitting around one table next to wipe boards filled with thoughts, requirements, plans, etc. The energy levels were high and everyone was focused on the short time they have together to ship this new product and form the foundation of a future company.

One of the disadvantages to selling the agile philosophy to this type of audience is that they aren't overcoming a legacy of problems. Instead of talking about the "downfalls of traditional management" and sucking them into the "wonders of agile", you have to focus on a completely different issue. Instead of saving them from their past, you are instead trying to save them from their future.

It's almost like startups are agile by their simple nature! And it's our job to point at the things they need to protect as they grow (team culture). We have to point at the guardrails they should put into place today before they are too large to recover (examples: focus on technical debt and backlog management). Their team behavior is such that they "just do stuff".

It's very similar to the environment I'm in now. It worked well under 30 people. But when my company grew to 60+, suddenly we needed some process. So, what does all this tell me? It tells me that it's time to start working on those slides for Agile 2010, because this is the exact topic I'll be talking about (Agile Transitions). See you then!

Keep your stinkin' Maturity Model - prescriptive vs. adaptive

I keep seeing the same question appear in many forums lately- "How do we create a CMMi-like Maturity Model for Agile?" Sometimes this is a global question for the community, sometimes it is a question focused on a specific organization.

A couple of thoughts:

• Not all problems can be solved by the same solution
• Not all teams have the same problem
• Not all teams have the same dynamic and ability to change
• Thus, not all teams will succeed with the same set of instructions
  
• But, all teams can be aided by an experienced mentor/coach

Whenever I hear of Maturity Models, I foresee an environment where the desired process is documented and stable, and the steps to evolving to it are prescriptive, standardized, and audited.

The problem I have with this is that it will most likely constrain the teams ability to explore new ideas and solutions to their problems. Their continuous improvement will most likely be driven through a canal that is managed by lock keepers and limited to the waterway. Kanban has had a refreshing influence on the community, but it is not for everyone. Does an organization create a maturity model that takes in every new idea? Does it have the capability to create a choose-your-adventure pathway?

Yes, I think an agile transition maturity model is possible. But I also think it is improbable to have the right outcome. And, it might be less work to allow the teams to find their own way with a centralized coaching/mentoring staff. What do you all think?

From a recent LinkedIn conversation I was having:

I would suggest that a first step is to inspire the PMO group in your organization to get out and observe the teams. Start documenting patterns. When there is a catalog of "for this problem, here are solution patterns that have worked", you not only have teams learning and growing from each other, but teams of like need mature towards a converged point.

Personally, I'd prefer this over a CMMi approach because it is a mentoring/guidance solution instead of a prescriptive/directed solution. The minute you demand teams follow a certain path, you limit their ability to explore and uncover great ideas. I believe that creativity and exploration through retrospectives is a key part of continuous improvement.

Why use the term coach?

In my work, I've had many labels applied to me. On bad days, they may not be so pretty; but most days, they are terms of endearment for what I try to provide the people I work with.

Recently, I got in a discussion about these terms and why "Coach" was the best term (other terms included: shepherd, evangelist, guru).

Coach is a great term because a coach is a person that is invested in success/failure (winning/losing), but isn't normally on the field doing the work. Their job is to provide the mentoring and tools (and environment) for the team to be able to succeed. They rally the team when they are down, and they point out the obvious when the team won't face it. They uphold the team values, and drive them to continuously improve. Finally, the focus is never on the coach, but the team's performance.

This is true in sports, and is true in agile environments.

Book Review: Agile Coaching (Davies/Sedley)

Due to the second part of the Snowpocalypse here in the Northeast (3-4 feet in less than 7 days!), I had the opportunity to work from home and catch up on some reading.

The first selection was "Agile Coaching" by Rachel Davies and Liz Sedley. This book is part of the Pragmatic Programmers publishing series.

This is a great book with lots of modern concepts included. I was surprised to find notes on Kanban and Pomodoro included in sidebars since these concepts just became common/mainstream knowledge in the community in the last year. As a whole, the flow of the book and the ideas contained were well-organized and easy to absorb.

My only disappointment with the book is that I was hoping for a whole book on improving as a coach, but this was limited to the last chapter. The majority of the book was focused on various slices of agile and how to facilitate them. Because I was lucky with my entry into agile (I was mentored by great coaches from ObjectMentor), many of these thoughts had been planted in my head years ago. It was good to refresh them in a simple condensed fashion though.

Summary- I'm glad I have this book in my library. It may not have provided new information for me, but it is a great reference in times of stress when teams slip back into old habits. It provides a great reminder for me of things that I sometimes forget. More importantly, the book can be read in slices which makes it a great tool to hand to others to learn a specific concept. I think target reader should be anyone new to agile that is in a leadership role (note I didn't say management). I have a strong feeling that I may use this book heavily as a tool to provide insight for others.

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.

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.

Participate in change, don't expect it to happen

One of my peers asked me why our manager kept assigning work to specific resources instead of simply prioritizing it and letting the team pick it up as people were available. The upside of this question is that they are starting to understand some of the core agile concepts, but the downside is that this is a hard question to answer. What they want to hear is that I will go convince management to stop meddling with the team and allow them to be self-empowered and self-managed. They want to find the better way on their own, but it's not that simple.

The manager does this for a reason. To him, it is important to sort his desires taking efficiency into account. In his mind, this is most affected by WHO is going to work on it. Instead of pushing for anybody to be able to work on anything (something that seems insurmountable), he re-arranges his desires and works with the system in place. Unfortunately this is a very short-sighted approach, but we haven't provided much of an alternative. Right now, the manager only trusts himself to make these decisions.

I pushed back on my peer. I told them that it was up to the team to change this situation. We have to do more than simple code reviews. We have to actually insure that multiple people on the team know how everything works so anyone can modify it. We have to build trust with management that we can handle work efficiently in whatever order it arrives. It is a slow path to managers having the freedom to prioritize and granting the team control to manage themselves. We have to build the solution, show it exists, and earn management's trust.

I find it is easy to convince a team of the underlying agile values and principles. The harder part is convincing them that they are an active part of the solution. They see all the ways agile solves their needs, but they forget the needs of the business and management. Teams must take ownership of showing managers how agile solves their needs also. Everyone has to understand that we are trying to optimize the whole system and not just the part that the team plays!

Gaming the System: Velocity...

To take my previous point further (prior post), Alex Hamer wrote an interesting post about how his management wanted him to "find ways to improve velocity". He correctly considers things like training and coaching, but is concerned that management isn't thinking down the same lines and is "approaching with caution."

I've seen this management request before. Typically it comes from the frustrated Product Owner who projects the current velocity against his "desired release scope" and is frightened by promises he has made to customers. He understands the new system and velocity, and decides to use the "whole team" concept to suddenly include you in the problem. Next thing you know, he's standing over the team asking for "more velocity!".

Feels like the old way of working again, doesn't it? Agile doesn't solve the problems you felt under waterfall, it simply exposes them in a big ugly way. You can either cave and play the old games, or you can hold your ground and help management become agile with you.

Here's my sarcastic advice to Alex:

Your gut is telling you the right thing... you don't forcefully "increase velocity", you have to help your team get what they need and it will increase on its own over time.

The easiest solution is to start accounting for the velocity of vacations and conferences or training. These are guaranteed points and therefore will drive up the average. After a few sprints of the higher number... disclose that you've gamed the system. Then drive home that forcing metrics only forces gaming of the system. Remind them that this is why waterfall fails in most environments. They are only pushing you to go back to the old way of doing things under a new name.

Help your project sponsor become agile!

How to manage various personalities...

You shouldn't have to manage them, only coach/advise them. Period.

In "Good To Great" by Jim Collins, he spends a very important early chapter on the concept of "getting the right people on the bus", "in the right seats", and the "wrong people off the bus". He even goes as far to propose that heavy management hierarchies are a compensation for having the wrong people on the team and needing to manage them. (Note: this is the chapter after he explains the 5 levels of leadership, so that is not the assumed cause of issues.)

Why am I mentioning a great business book on an agile blog? Here's a question from a LinkedIn group:

From the Manifesto - The best architectures, requirements, and designs emerge from self-organizing teams.
This seems to do away with the team structures. Wouldn't it be disruptive, given the various personalities that a team can have?

I read into the "various personalities" phrase; here's my response (still waiting to see what others say):

Does the team have "personalities" that can't act professionally and in the best efforts of the team unless their role is clearly defined and with boundaries?
If this is true, I would argue that managing those individuals cost more productivity than they provide in both the waterfall and agile environments. They need to be molded or removed.

It might seem harsh, but we need to insure that teams are enabled by their members and not hindered. I know it is hard to find great people, but when we do hire, they should not only possess the required skills but also fit the culture of the team. Here's another take on this topic from Johanna Rothman.

Higher Agile Project Performance...

Recent VersionOne user forum discussion:

How to yield higher agile project performance? Should we implement one agile method, such as scrum, and follow process rigorously, or mix with different agile methods?

I'll paraphrase my response:

As mentioned previously, I'm a believer in Shu Ha Ri. This means, follow the book until you know the why behind the prescribed actions. Do not modify the process unless you know what is removed with your proposed changes. Many people lose more than they gain if they change a process before it is fully understood.

Many waterfall projects could be successful if the team studied and followed the PMI process as documented. Agile will be corrupted just as quickly as waterfall if people keep bastardizing it blindly as they have been. If you are interested in expert opinions on bastardized agile process, check out Jeff Sutherland's view's on ScrumButt and the Nokia test.

My proposal: apply Scrum for people, business, team, project management improvements or apply XP for engineering practices and technical quality issues. You could apply both simultaneously, though this might increase risk with too much change at once. Scrum requires a top down implementation, while XP should be a bottom up implementation (I'm speaking of the top/bottom of your organization).

Eventually, you can yield a higher agile project performance with a blended process approach based on your environment, but you can't jump directly there in the beginning. Also, the person driving your Ri level approach should be experienced (not just trained) in the things being blended. If you do not have this person, then the changes need to be a gradual evolution (one per iteration) allowing for correction.

I would debate that the average team should get through twelve iterations before trying to tweak this. For one month iterations, this is a year. For two week iterations, you might be ready after six months. Why base this on number of iterations and not time? Because you should be learning with each cycle and improving from your retrospectives. Agile is about learning and adapting, not practicing (or feeling pain) over time.

The last option I would throw out is that you don't implement anything by the book... you simply add one practice every two weeks or month. The practice added is one that addresses your biggest pain of the moment. Over time, you will back into a blended agile process that works well. Unfortunately this requires two things... lots of time and patience, and someone with experience to make the right selections at the right pace and help the team implement it in isolation of the rest of the practices. I've seen this work only where the person driving has had experience with a successful multi-year mature agile implementation in the past. If you are going to choose this path, I would suggest the following sequence: retrospectives, standups, large visible charts. Why would you choose this path? Because nobody has bought into agile and you just want to solve the current problems with agile patterns.

Manager type: Curler

As a manager, you’re the guy on the Curling team with the broom – sweeping the snow out from in front of the stone… You don’t want to be in their face with all the details, but here to remove obstacles.

Excerpt from his list of advice to new team leads.

Agile Planning...

Two reposts due to their interesting topic and unique content:

• One of my more recent and popular posts was about creating a proper estimate scale. Here is a great post by Bob Hartman about how to improve your poker planning activities. Use it to build on top of my advice!
  
• If you are curious to read a great overview on agile written by a User Experience expert from IBM, I found this quite good. Nothing new for the experts, but I like having good summary resources to leverage when coaching. I also found it interesting since it's coming from such a large company.
  

Sprint Committments...

This post is my response/summary to a thread on the Agile Alliance LinkedIn group related to the same topic. If you'd like to read all the details, click here.

The question asked by Rene Rosendal was:

I've seen teams who don't seem to take their sprint/iteration commitments very seriously. When a story is in jeopardy, they don't increase their work intensity in the attempt to finish it. Instead, the words "well, we'll just have to carry it over to the next sprint" pass their lips very easily. Obviously the Scrum Master or Product Owner cannot "force" the team to work harder and make things happen. ...

My response was three fold:

• Assuming they made the commitment, you have a team / culture problem... lack of caring or motivation
  
• Or you have an empowerment problem. The team is not actually committing, but someone else is declaring commitment for them. I've seen management assign the sprint goal and work. How can the team commit to something they know is not possible just because someone said it? The team should own the sprint planning session of work.
• Or you have a communication problem. Maybe the team is committed and they selected the work. But the point of agile is that things change. Maybe they found things during the sprint that made them realize the commitment was not obtainable. Did the team go back to the Product Owner/customer and clearly communicate this? Did they negotiate? Did they make sure that the work they were pursuing was still correct in light of this new knowledge?

Other great points:

If the team puts in extra work to complete a story are they penalized by having the organization expect that they will do the same number of points in the next iteration? - Rob Scott

Most sprints my team fails to complete everything on the Sprint backlog. We do not consider this a Sprint failure. Instead, we remind ourselves to focus on getting the topmost things on the backlog completed first, so the items of greatest priority are done by Sprint review. I think this is extremely common. - Dan Greening

Is the product owner easily accessible to the team and actively involved during the sprint? - David Sallet

Fundamentally, commitment is like trust... you can't make it happen, it is chosen by the holder.

The 4 stages of competence...

No, they aren't idiot, fool, apprentice, genius. Here are the four stages of competence:

1. Unconscious Incompetence - The individual neither understands or knows how to do something, nor recognizes the deficit or has a desire to address it.
2. Conscious Incompetence - Though the individual does not understand or know how to do something, he or she does recognize the deficit, without yet addressing it.
3. Conscious Competence - The individual understands or knows how to do something. However, demonstrating the skill or knowledge requires a great deal of consciousness or concentration.
4. Unconscious Competence - The individual has had so much practice with a skill that it becomes “second nature” and can be performed easily (often without concentrating too deeply). He or she may or may not be able teach it to others, depending upon how and when it was learned.
- Wikipedia

Thanks to Jerome Gagner for sharing in his recent blog post on the same topic. These ideas fold nicely into the Shu Ha Ri ideas discussed before.

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?

ScrumAnd, not ScrumButt...

Repost: Ola discusses the difference in climate, attitude, and outcome when we switch a conversation from "Yes, but..." to "Yes, and..." Not only is this an interesting coaching/team culture thought, but it ties in well with the ideas around Scrum, Agile, and the different disciplines (and how they can be combined).

I believe ScrumAnd already exists. Under a different name though. It’s called eXtreme Programming. It’s Scrum and programming practices. Now you might say. ‘Well, Scrum deliberately says nothing about programming practices. You can use Scrum to plan and execute anything’.

Yes, that’s true and that’s the problem. People are now cranking out crappy code at least twice as fast as they used too.

Read the full post "What About ScrumAnd" here.

Our chosen language...

No... not the programming language.
Not even English vs. French/Spanish/etc.

Language... as in tone, rhetoric, choice of words.
Is yours offensive, passive, strong, dull?

Some people are inspired by strong words, some people are offended by it. Attention is grabbed with certain words, but what kind of attention?

What do you use in your daily conversations with others?

Why does this matter?

If you are a leader (an agile coach, scrum master, tech lead)... then this is important. As a leader, you mentor constant change. For this to be successful, positive change... you have to insure the team as a whole is working together. To do this, you have to sell the idea, plant seeds, mold minds.

You are the salesman. You make the pitch.

Pick your words carefully.

This post was inspired by the struggles of my esteemed mentor in the pushback on the word "sucks" as part of his presentation title at Agile 2009. Here is a portion of my thoughts back to him:

I totally understand your predicament. I agree with you that words like "suck" and "crap" have been used at our agile conferences (in keynotes) in a manner the implies they are accepted. Strong words to invoke strong emotions. I tend to get in trouble as an agile coach when I use strong emphatic words... they do catch attention, but not everyone is comfortable with their strength (and implied negative connotation)...

... I think the lesson here is that [strong] language IS acceptable to put the final nail in a point being made, but maybe not acceptable as a way to introduce it. It is acceptable within a controlled and known audience, but not to the world at large. Personally, I don't like this... but I've accepted that being a good coach/presenter is being a good salesman... which is knowing your audience and exposure and adapting to it.