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.

Is Agile a more humane way of working?

This was the question asked in the Agile Alliance LinkedIn group, and the question was focused on agile vs. other methods. It questioned whether the manifesto itself was written with the human element in mind, or whether it was focused on efficiency and outcome only (the human element being a byproduct). Additional points mentioned the 40 hr work week (as opposed to more) and sustainability.

The first three responses dissappointed me since they were non-answers.

1. I wasn't there, we can only guess (as if we've never heard the authors speak since then!)
2. I'm not sure, but it is at least more natural
3. Self direction creates a perception control and therefore happiness

Not being one to sit idly when there is an obvious answer, I had to state the following:

Yes!

The 8th principle of the Manifesto - "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

BTW, many mature XP teams will peak around 35 hours, not 40. Pairing and TDD is very intense. You get the most around 35 hours, and productivity can start decreasing between 35-40. But this productivity is higher than the prior 45-50 hr weeks. I've both seen this and heard about it from others.

Cesario Ramos chimed in also:

The lean and agile thoughts explicitly make human values to be the center. It promotes an environment where every individual can use its potential for developing itself and its company. An environment where people can be part of a team and can contribute to a higher objective.

So in my opinion, YES, it is a more humane way of working. Even if the intentions of the agile approach are just to make more money.

There is that caveat that every idea can be destroyed and that there are plenty of companies that use Agile to get more hours out of their people. But, when I see this, I tell those that are suffering that their pain is inflicted by people, not by trying agile (and they aren't doing agile)!

My Overview of Agile Presentation (to a local PMI Chapter)

I was invited to give a talk about Agile to the Delaware Valley PMI Chapter on January 7th. The audience was going to be filled with local PMP's, some of which would be skeptics, and some of which would have been burned by bad agile implementations. I was worried about how to normalize their knowledge, and I had to do it in less than 45 minutes so there was room for Q&A.

Once I realized that I couldn't cram Scrum, XP, Lean training in along with a proven case study... I decided to go for the overview and provide them what they needed to find out more. I wanted the group to understand the Scrum is Agile, but Agile is more than Scrum.

As far as I can tell, the session was a success. I got positive feedback at the end, and I felt I made the most of our time.

If you want to get a copy of the slide deck, you can download it here. Since I'm not that popular of a guy yet, hopefully this won't overwhelm the daily bandwidth limits of my personal website traffic restrictions. If you get nothing, email me or put a comment on this post and try again tomorrow (and I'll have to move it to another host).

Having been through this experience, if there is anyone in the Philadelphia region that is interested in having me come talk about Agile or some specific piece of it... feel free to contact me. You can find many ways to reach me on my personal site.

What if Congress used Agile?

Eric Camulli posted this interesting question in the Agile Alliance LinkedIn group:

Could Agile help Congress with healthcare reform? I'd like to see someone take a stab at applying scrum principles to the "great development project" of our day...

Our country's healthcare "project" could end up looking like many Waterfall projects...not on time, over budget and not meeting customer's needs in the end.

Unfortunately the conversation quickly started to veer off into moral, ethical, and political opinions/viewpoints/jokes unrelated to agile...

But I thought about this a little bit and I did find some comparisons between our legislative system and large companies that aren't agile. Here is what I ended up writing:

I think the real problem with anything going through Congress is that they don't "go to the gemba". They rely too much on research and lobbyists to translate the needs of the "customer" for them.

Congressman act as if they are Product Owners, but they don't have the domain knowledge or "end user" interaction to truly own that role.

So... I guess my solution is that we need to find a way to decrease the feedback loop distance between those affected by policy and those creating it.

Does anyone else have any ideas or insight into this one?

Individual Recognition on a Scrum team

Hmmm... another conversation in the Agile Alliance LinkedIn group. Here was the question:

Should we have an individual recognition award in a SCRUM team? Lots of people says that individual award is against an Agile methodology. Award should be given to a team not to a individual team member.

I tried to play a passive role and stated the following:

I have seen these conversations occur many times in many forums and the end of the conversation always results in a "NO" with a very good list of reasons. The risks outweigh the rewards no matter how you set it up.

There is a gray area of disagreement on whether the team can spontaneously award a peer or not. But the minute you make it a regular event, it wanders back into the problem area.

The best reward is taking a respected peer out for coffee/beer and telling them you appreciate their contributions, or saying in front of the team what good they've done. This doesn't need to be organized.

And the first few responses before mine were in line with this:

If you want to have a well jelled team - absolutely not.
The only exception I can think of is if the team requests it.
But that sets up a conflict of interest. - Jay Conne

The only time an individual award is appropriate is if the team wants to acknowledge an individual who has made a significant contribution that made a big difference TO and FOR THE TEAM. - Shane Hastie

But then we got the extremist viewpoint thrown in:

The Communists tried the concept of Co-Operative farming. Under that framework, no individual was supposed to be better than the rest. Needless to say, the concept didn't work out.

So I found myself having to take a stance and state the following:

Here's the best way to summarize what I'm insinuating/feel:

If an award is financially valuable... and it is regular (creating a sense of expectation), then it has a higher probability of creating individual behaviors over team behaviors unless your team remains constantly aligned to itself (resources typically fluctuate too much for this to be assumed).

If a reward is simply a show of appreciation and a call to what behaviors or achievements the team should continue to grow and repeat, then this has a higher probability of creating a collective and positive team behavior, especially if it is unexpected (not scheduled), and driven by the team.

Feel free to include your own thoughts in the comments, but I have to say that I'm not very open to debate on this one.

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.

Agile is not a metric, it's a journey...

As ridiculously fluffy as that sounds, it is true! You can't measure your team's agility and say, "Yup, we are there!". It is a mindset. All of the agile approaches (XP, Scrum, Lean, etc) are simply schools of thought.

Jai put up a very good post which triggered this discussion:

... Then he added that if you are not doing pair-programming or continuous integration, how can you say that you are agile. There I got the idea that what he was confused at.

Sometimes it is hard for people to differentiate and digest the differences between the Agile practices and many of the XP practices. They somehow get mislead by the idea that the XP practices etc are part of Agile. And Agile enforces these practices with it.

Many interesting comments are starting to come in, but mine was this:

I’ve dealt with this myself. I try to explain that the manifesto was the result of many people with different ideas on how to solve the same problem. The manifesto is the solution to the problem strategically. The “denominations” of agile are tactical approaches to solving the problem. Scrum is product and schedule focused, XP is engineering focused. And oh yeah, many of them have converged over the years.

Contrasting XP/Scrum with Kanban, Crystal, Lean, etc also tends to help. When people can see the common outcomes from the different approaches, it starts defining Agile by the results and not the chosen methods.

Follow the discussion further here.

Agile FAIL!

Sometimes I feel like a fireman... I read things that just don't make sense and I want to pour water on it and put the fire out. I have slowly come to realize that there are more voices proclaiming stupid things about agile than I can counter.

Let me share with you what bothered me today...

Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’.

Yeah... this is a FAIL! (on the part of the "Agilists")

Most IT projects exist to enhance the capability of the organization.

I'm not completely sure what "IT project" means in this context... but they don't exist for the organization. All projects are about business value and enabling profit.

Partial Fail?

...at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed...

Documentation is needed in a minimal sense... but whatever happened to working, accepted, purchased software as the best measurement?

Partial Fail!

The agile extremists may do well to consider [self discipline] and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

Very good point. Whoever this person got their impression of agile from.... VERY BIG FAIL!

Say what you'll do, do what you say...

I've been noticing something new lately. I schedule a meeting and everyone confirms it, then about 30 minutes before the meeting several people come up to me in person or by phone to confirm that we are still having the meeting.

What?

Am I that distrustful or unpredictable? Is there a history of you showing up for meetings and them not occurring?

I'm confused by this... but then I got to thinking about it more. I realized that I've had friends or family do it also with gatherings. This behavior has risen in the last few years. What I don't know is if it has anything to do with our constant micro-distractions with technology, or a decrease in respect for each other.

Don't get me wrong, it bother me that people waste my time to verify that I won't be wasting theirs... but what I'm really concerned about here is that people do this to protect themselves against something that must happen to them all the time. This something is hugely disrespectful. It's the act of not following through.

I was raised in a community and culture where you stated what you were going to do, then you did it. If for some reason you couldn't, you had better set expectations in advance as soon as you could. If you didn't, you paid the price by harming that relationship. You didn't deserve to receive mutual agreements from that person in the future after that mistake.

Agile is about this. Standups inspire this. Reviews demand this. Planning and Velocity requires it. WIP limits assume it (I've seen managers bypassing WIP on the sly!). Retrospectives if run properly will inspire it also. Without it, everything starts to fall apart.

So people: say what you'll do, and do what you say. Follow through. Get to DONE! And don't limit this to your work, but include it in your relationships with other people.

Think about how much time we can save not second guessing stuff anymore!

Before agile came along, life was easier for me...

The problem with Agile is that it helps us realize early that there might be problems. Granted, this gives us time to solve the problems and get the project on track, and it allows us to have a higher success rate.

But I miss the good old days where we happily worked for months until the death march started. It allowed us to stay blissfully happy and then blame management for the last 3 weeks when things went wrong. Some of us would get good at finding long projects where we could work for months on lines of code and then bail on the work and jump to another job or company right before it went into the crapper. Becoming an expert in our skillset was simply about perfecting our selection of projects and timing them well.

Now we actually have to be on top of our game every day! That's a little bit more challenging than I expected. I went and got this computer science degree so that I could sit in a cube and write code and get paid lots of money for it. What's going on here?

Yeah... unless this is the first time you've read my blog, you know how I truly feel!

Read the Cutter Consortium's version of this viewpoint.

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?

Agile and offshoring... why it doesn't completely suck.

There have been a few posts recently in various forums about mixing agile with offshoring. At first I had a repulsive taste in my mouth. You see, I've never been in an environment where offshoring has decreased the cost of development while maintaining a similar level of quality or time (or reduced the time with the same cost). I'm not saying that it is not possible, I'm just saying that the companies I've worked in that tried it have not been good enough to make it work in their favor. In my last group, we practically had an A/B test team that proved this for me.

My personal history was then combined with my positive experiences with agile and co-located teams. I saw the huge productivity gains when everyone on the team was moved into a single room together. I saw similar gains with the product owner was moved nearby and the usability and testing roles were given hotel desks in the room to spend part of the day (they were matrixed, so they spent 2-4 hrs a day in the room). To me this was proof that closer was better. Time zone issues, communication issues, latency of conversation, team chemistry.... all of these things improve with co-location. Accountability is much higher because you can see the peer that made whatever statement.

Thus, my view was always... why would I want to work on a team that isn't co-located? I hold high expectations of myself and my work. Why would I want to immediately suppress my potential by being in that situation?

But this week, I had a new thought. Some companies offshore. Clearly the model has to work for them to continue to follow this model (or they are complete idiots). Does agile improve this model?

Yes! It would! Agile is greatly about quicker feedback loops. What better way to uncover communication gaps, quality and time issues, or any other set of problems than by shortening the window of time before you uncover them?

So... I'm suddenly in a new camp. Agile and offshoring is not a bad idea, it doesn't completely suck. Actually, if you feel that offshoring is your necessary way of gaining an advantage, then agile might be one of the only ways to manage it well. Instead of looking at offshoring as a way to ruin agile, I'm looking at agile as a way to improve offshoring.

That being said... I still want to work in a way where I can be face to face with my peers at least weekly.

Disclaimer: In no way do I want to reflect any discrimination or judgement about people in offshoring centers. Many of the people I've worked with in India, Romania, or Germany are equally capable as people I've worked with in the states. I believe the disadvantage of offshoring has nothing to do with the individuals and all to do with the structure/model in which it is set up and managed. The point is that it takes extra cost to manage, and this is a cost that doesn't exist in a co-located setting.

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!

What is a self-managed team?

I previously discussed a LinkedIn discussion thread about team's and various personalities. (Here's the LinkedIn discussion, and here's the prior blog post.) I focused on the personality aspect of the question, but Hemant came back with another question:

It is not yet clear what a self organising team really means / stands for.

Having spent some team managing teams, am yet to see a group of individuals so completely balanced that they choose the right approach without getting swayed away by a particularly persistent individual. [who in all probability is from the business side of things and insists on providing solutions instead of requirements].

Guess more efforts/reading is required on my part to understand this better..

This is a great question. I wonder how many people think that self-managed is focused on the roles of the team vs. the needs of the team from outer management? Here's my attempt to define a self-managed, self-organized team:

A self-organized, self-managed team is a team that needs little influence or direction from the organization above. The team itself becomes very good at working with the Product Owner/customer and knowing what to do next. There is little need for a project manager or resource manager on a day to day basis.

On some teams there are passive leaders, on others everyone plays an equal part. But the point is that they no longer need direct instruction/orders from above because they are more in tune with the customers needs. This allows the upper organization to be lighter (cheaper) and focus more on strategy instead of tactical issues.

What does self-organized and self-managed mean to you within the Agile domain?

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.

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?

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.

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?