I had a fun experience last week that I want to share with you guys. It was my first week with an awesome new client. The plan was to start with two days of general agile training, followed by a day of release planning workshops, and then iteration planning. Once the team starts sprinting, I'll come back for a day a week to do a little coaching, and to help keep everything on track. All in all, a pretty standard engagement.
This team has a solid product vision, and a pretty good understanding of their features and needs. The features and needs were pretty easily translated into high-level, value driven epics. We spent some time breaking down the first set of features into finer grained user stories. Because the team was new to agile, and really had no idea of their capacity, we took the extra time to break their user stories down into tasks.
Okay, so you guys know the drill. User stories get estimated in points, tasks get estimated in hours. We decided to use the Fibonacci series for the user stories, but the team wanted to use a binary sequence for estimating task hours. I'm okay with either... and since it's really not my call... we went with binary. The only problem was that we didn't have enough binary planning poker cards so that the entire team could get involved. We had to get creative.
The ideas came quick, but what we ended up with was a version of the old rock-paper-scissors game. Someone realized that each of the allowable estimate values, could be represented as a single digit, using a power of two...
1 = 0
2 = 1
4 = 2
8 = 3
16 = 4
32 = 5
...and, we could each vote with one hand by throwing the exponent, rather than the entire estimate value. Only, in a room full of software developers would someone come up with that. It was elegant... it was geeky... we could do it without supplies... so we went for it.
Since there was no way to hide your estimate using fingers (say, by putting the card face down on the table) the developer leading our session introduced the rock-paper-scissors idea. But... rather than saying rock-paper-scissors-shoot... he went with Ro-Sham-Bo-shoot. I had never heard that version, but once again... it was funny... it was geeky... and the team loved it... so it stuck. Each time, after they talked about a task, someone would look around and ask... 'rochambeau' ?
Once everyone agreed... they played their hand... literally.
It was an awesome... fun... emergent experience, and we came up with a new approach that I am sure I'll want to use with other teams. The estimating went really fast, faster I think than messing around with physical cards. Either way, it was a great team building experience. It was a creative and effective way of playing planning poker. I'm curious if anyone has every played planning poker this way? Is it documented somewhere?
If you happen to be interested... here is a link to the Wikipedia entry for Rochambeau.
http://en.wikipedia.org/wiki/Rock-paper-scissors
The Urban Dictionary had a much more colorful explanation... this one made me laugh out loud.
http://www.urbandictionary.com/define.php?term=ro-sham-bo
Give this approach a try and have some fun with it!
Need training, coaching, or help leading an agile transformation?
email: mike@cottmeyer.com or call: 404.312.1471
Monday, June 28, 2010
Ro-Sham-Bo... Shoot!
Sunday, June 20, 2010
Interesting Post... 6/14/2010 through 6/20/2010
PMBOK, Agile, and Some Tips http://bit.ly/bA10TB
Connecting the Dots to PMBOK http://bit.ly/aQXo1w
Are things getting to complicated? http://bit.ly/93cV9r
8 Habits of Highly Excellent Bloggers http://bit.ly/cnIbX5
Getting Ahead, Really? http://bit.ly/cSG3D1
8 Transformational Leadership Lessons From Seth Godin http://bit.ly/dcdLxA
Stop Whining and Get Started! http://bit.ly/aWtuJZ
What Does It Mean to Be Agile? http://bit.ly/daoMJc
Using Agile To Scale Agile – Part 1 http://bit.ly/cbMJ3M
Fridays Digest #18 Scrum vs. Kanban http://bit.ly/968w3L
The Pepsi Challenge of Waterfall Agile or Kanban http://bit.ly/clDBr7
Agile in Everyday Life http://bit.ly/8ZJNly
Your Software is not a House http://bit.ly/a98OPH
Scrum and the PMBOK http://bit.ly/daxNlc
New to agile? Learn how to fail well http://bit.ly/d6wVj3
The Context Machine: The Essence Is Context http://bit.ly/adHbT3
T-Shaped People http://bit.ly/92aQK9
Change Without Motivation http://bit.ly/c7amuo
Come Play Innovation Games for the Agile Developer Skills Project! http://bit.ly/c5omCk
ScrumMasters Now Earn More Money Than Project Managers http://bit.ly/92ahVw
Kanban: What are Classes of Service and Why Should You Care? http://bit.ly/aodC4t
The Oath of Non-Allegiance http://bit.ly/91Pxhh
Your Product Is Done http://bit.ly/dmn9aT
Wednesday, June 16, 2010
Let's Define Our Starting Place
I'm telling you guys... if you're not participating over on the AgilePMI Yahoo! Group, you are missing out on some great conversation. Think about it... this is THE issue going on right now impacting the agile community. We talk about agile and transformation... but the traditional establishment holds the keys in most of our organizations. Unless we can show them how to transition safely, we are relegated to bottom-up, grass roots agile initiatives... most of which have a very low probability of making any kind of meaningful difference in our companies.
That said, one of the problems I think we have... not just on the Yahoo! group, but as a community in general, is that we often talk past each other on pretty key issues. I was going back and forth with Dan Mezick and Dennis Stevens on the idea of team authorization. All of a sudden it dawned on me that Dan and I agreed in principle on where we wanted to take the organization, but Dan wanted to discuss the organization as it should be... I wanted to talk about the organization as it was, and how we can be successful in it.
It seems to me, that in any conversation, we have at least three possible starting points for debate:
1. The current state
2. The future state
3. The transition state
My guess is that most people in the group agree that something is wrong with the current state of software project management. That is why they spend time reading and posting and exploring how to do things differently. I'd also guess that most folks in the agile community agree on the ideal end state. We might have some differences of opinion around Scrum or XP or Lean or Kanban, but I think we all value the idea of empowering teams, respecting individuals, and helping organizations deliver the most value possible.
Some of us are so passionate about the way things should be, that point of view becomes the starting place, and they argue for change right now. Others of us have heard those messages and found that they don't resonate given the current regulatory climate in our companies. These people want to talk about what they can do today... without some sort of massive transformation. They don't have any clear way to make the kinds of changes that the 'future state' people are advocating. Others, like me, want to talk about how to get from point A to point B as safely as possible.
Understanding the point of view from which the other person is arguing from can be really valuable as we're trying to move this discussion forward. I hate seeing us run in circles with each other when there is probably more we agree on than we really think. The futurists hold the vision, the today people have the current reality, and the transition folks want to find a way to bridge the two. Maybe if we can start our conversations by clearly stating our starting point... and have more meaningful discussions around all three different viewpoints... we might have a way of moving this thing without constantly going around and around, without ever really increasing our understanding.
By the way... here is a link the Agile PMI group if you are interested in joining the conversation:
http://finance.groups.yahoo.com/group/pmiagile/
Monday, June 14, 2010
Fundamental Attribution Error
Anybody ever heard of this phenomenon? Here is the definition from Wikipedia:
In social psychology, the fundamental attribution error (also known as correspondence bias or attribution effect) describes the tendency to over-value dispositional or personality-based explanations for the observed behaviors of others while under-valuing situational explanations for those behaviors. The fundamental attribution error is most visible when people explain the behavior of others. It does not explain interpretations of one's own behavior - where situational factors are often taken into consideration.
When we talk about methodology and roles, how often do we attribute to the methodology... or the role... some sort of evil bias? How easy is it to dismiss traditional project managers as command-and-control, when in reality, these people are doing the best they can, given the situation in which they find themselves? Do we acknowledge that these people are only doing what the organization expects of them?
How often do we give a failed Agile project a pass, maybe on the basis that they 'tried' or were 'fighting the good fight', but view every failed waterfall project (and the traditional project manager running it) as incompetent? Do we ever acknowledge that people in these projects might just be playing the hand they were dealt? Working within the system they were hired to support? That the very structure of the organization around them accommodated no other way of moving forward?
If we want people to behave differently, we have to be able to influence the systems that are driving their behavior. I'm telling you guys, much of what we talk about in the agile community does not play well in the environments where many traditional project managers find themselves. Company culture and organizational structure drive behavior. Until you address those fundamental structures, meaningful change will be hard to come by.
The problem isn't the people involved, or even the leadership... the problem is the system in which those people are operating within. People want to be successful, but if the system around them is not conducive to empowerment and self-organization, people are going to change until the system changes. Authorized teams, without the appropriate organization to support that authorization, will expose both the company and the individual to an unacceptable level of risk. We've got to acknowledge that risk and help people deal with mitigating it.
More scout stories from our brutally hot week... I think my 14 year old son has gone insane... Watch out... this clip is PG-13!
Sunday, June 13, 2010
Interesting Post... 6/6/2010 through 6/13/2010
Silly Saturdays: Mac vs. PC http://bit.ly/cGd2ve
The Reality of UI Test Automation http://bit.ly/9Oi0sS
Projects that are NOT Agile Software Projects http://bit.ly/akTOJa
Fear of shipping http://bit.ly/9xjhna
Agile Isn't Latin http://bit.ly/9WFS22
The new CST application process http://bit.ly/ccsNrW
Status Reporting Intervals http://bit.ly/d5VSTs
Are you being creative? http://bit.ly/dwR69w
PMBOK is NOT a Method - Part Deux http://bit.ly/cka0ND
Kanban and When Will This Be Done? http://bit.ly/cohJ0n
Big Binders And Checklists http://bit.ly/ci0Sk3
The 19 Keys to Successful Agile Projects http://bit.ly/aEBXnJ
Scrum Gets Going In Bangalore http://bit.ly/aHrrQZ
PMBOK is NOT a Methodology http://bit.ly/cUyJVm
Artificial Critical Paths http://bit.ly/cypzpC
Base lining Story Points http://bit.ly/ajF9ix
Why Is There Still Talk About Agile v. PMBOK? http://bit.ly/9ojMy9
What DONE Looks Like? http://bit.ly/9gFksS
Schizophrenic Use Of Methods http://bit.ly/aQ7xy7
Agile is in the PMBOK so it must be true http://bit.ly/c4pw7L
Hyperproductivity in Scrum
Last year sometime, I had the pleasure of hearing Jeff Sutherland speak at the Agile Atlanta group here in town. One of the things that Jeff always brings up in his talks, is that Scrum creates hyper-productive teams. I asked him how he defined hyper-productivity, and how he measured it. He told me, but rather than explain my recollection of what he said, I want to reference how he explains it in print.
According to his paper Shock Therapy: A Bootstrap for Hyper-Productive Scrum:
"We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience."
Pretty impressive, but I am curious what the improvement is measured against. Going deeper into the Shock Therapy paper, the results from their MySpace experience say that:
"The baseline velocity (100%) is established for a team during the first Sprint. The Product Owner presents the prioritized Product Backlog in the Sprint Planning meeting. This is estimated using Planning Poker and story points. The team selects what can be accomplished during the first Sprint and the Product Owner determines exactly what is "Done" at the end of the Sprint. The number of points completed is the baseline velocity."
When I first read that, I was like "what am I missing here". Hyper-productivity is defined as improvement over the first iteration of a brand new Scrum team. That didn't strike me as a very fair metric, you'd think *most* brand new teams would get dramatically better after a few weeks of working together, using Scrum or not.
But here is their key assertion that supports the measurement:
"At MySpace, the baseline velocity is often significantly higher than their previously chaotic implementation of waterfall, so the baseline is conservative"
I don't know about you guys, but I'm kind of bothered by the assumptions, and the numbers that support them. Can we always assume the first sprint of a Scrum team is better than the same team doing Waterfall? I'm not sure. Are all Waterfall projects chaotic? I can tell you first hand they aren't. It might also be interesting to see the team stabilize first, and then see how much better they'd get by systematically removing impediments.
These numbers have been nagging me ever since I read this paper and first heard Jeff explain them. Is it only me? What am I missing here?
Saturday, June 12, 2010
Is Kanban just Waterfall with Small Batches?
Often when I introduce Kanban to teams that are just getting familiar with Scrum, one of the first comments I'll get is... it looks a lot like waterfall. So, here is the question, is Kanban just waterfall with small batches? Let's say you kept all your functional silos in place, and simply started running smaller projects... small to the point of being a feature or an MMF... would you get better business outcomes?
I haven't been in a situation where I could actually try this approach at any kind of scale, but my gut tells me that you would get better performance. You'd increase the rate at which the organization created value, you'd decrease the amount time spent doing up front planning, and you'd decrease the number of in-flight dependencies you're managing at any one time. Decreasing the batch size would make it easier to change direction when business conditions changed.
My guess is that's why some folks are so excited about Kanban... you get better overall performance, without having to change anything about how the organization is currently structured. You get incremental improvement without the transformation and change issues that come along with a Scrum adoption. In addition, you'd now have a way to explicitly visualize the work, manage the flow of value, and drive conversation that incrementally improves how the overall system behaves.
So... what do you think? Is this the preferred way of working? Do we abandon teams and transformation? Is adopting Kanban as simple as working on smaller batches, value stream mapping, and setting work in process limits to create flow? If we took this approach, what would be our tradeoffs? Would we be leaving anything out by not transforming?
BTW - It is worth marking the occasion... this is my 300th post on Leading Agile. That's kind of a cool milestone.
Friday, June 11, 2010
Motivation, Insight, and Introspection
I've had the idea for this post noodling around in my head for the past few months. To be quite candid, there was a part of me that wasn't quite sure how much of this I wanted to share. Even though I don't know all 2400 of you personally, I've always had this desire to be transparent. My hope is that that my experiences, agile or not, could somehow help you guys get better doing what ever it is that you do.
It's not been any secret, at least I don't think it has been a secret, that these last few months after leaving VersionOne have been really challenging for me. Working for VersionOne was a great gig. Someone else sold my engagements, and I just showed up where I was supposed to show up, when I was supposed to be there. When I wasn't on client sites, I did papers and blogs and attended conferences. It was a pretty fun way to make a living.
When I joined Pillar, all that changed. Now I was working constantly to build a business here in Atlanta. My life became all about generating sales. Rather than trying to solve the big problems in the agile community, I was trying to solve the big problem of managing a sales funnel and running a small consulting business. Much of what I'd been doing was brand new to me. I was like the guy that loved to make bread that opened a bakery. Now, rather than making bread, he was running a bakery. Not quite the same thing.
The time between the Scrum Gathering in Orlando and the LeanSSC conference in Atlanta was pretty tough psychologically. I spent a lot of my time stressed out, and sick to my stomach. There was so little correlation between the effort I was putting in, and the outcomes we were seeing, the stress was really getting to me. I wasn't writing, I wasn't connecting, and I wasn't enjoying life. To some degree I felt like I had lost my way... I had somehow lost sight of the big picture and what was really important. I needed to refocus.
Four books that helped me refocus
One night at the LeanSSC conference, I was sitting in the lounge having a drink with Jean Tabaka and Dennis Stevens. Jean was telling me about some of the books the folks at Rally were reading, and about how several of them were having a profound impact within their company. Jean turned me onto the first two I want to talk about today: Seth Godin's Linchpin and Daniel Pink's Drive. I like Jean, and I think she's smart, so I took her advice and started reading them.
Come to find out, some of the guys at Pillar were reading Drive too, and turned me onto a third book, by Chris Anderson, called Free. I think the Pillar guys are smart as well, so I picked up Free and starting reading it also. The fourth book was Gary Vaynerchuk's Crush It. I'm not sure where that one came from, but I'm really glad it showed up in my life. For me, these four books were the right four books, at just the right time. Together, they really helped me see, and articulate the core problem that I was struggling with.
I want to first highlight a few simplified takeaways from each book, and then tell you guys why there were meaningful to me.
Drive by Daniel Pink - The main point of this book is that creative people are intrinsically motivated. That means that they create for the joy of creating. They love being in a state of flow. They love being challenged. They love helping people. The idea behind this book is that people need to have their basic needs covered, but once that happens, extrinsic rewards don't increase performance. More often than not, they decrease performance. I have found that while I want to earn a boatload of money, it's not really about that. It's all about the intrinsic motivators. The money is a distraction.
Linchpin by Seth Godin - This was a big book with lots of big ideas, but I think what really resonated with me was Godin's take on how society is changing. The social contracts that told us to go to school, get an education, get a job, and conform... and in return society will give you lifelong employment... are broken. To be a linchpin, we need to think outside the lines. We need to be creative. We need to bring our passion. We need to give. We need to make ourselves invaluable by bringing our whole person to our jobs. This book helped me rediscover the path I had been on and why. Excellent book, my favorite of the four.
Free by Chris Anderson - I'm still reading this one, but the general idea here is that, as it gets cheaper and cheaper to distribute information, the cost of that information goes down exponentially... to the point where it is so close to free that it is less expensive to round down than to sell. In an economy of open source software and free services, how does someone run a profitable business. You give away one thing in the hopes of selling something else. Free helps me stay connected to people, to build relationships, until the right opportunity presents itself... and if it never does, that is okay too.
Crush It by Gary Vaynerchuk - Gary V. is a guy that turned a moderately successful local liquor store into a 20 million dollar business, and ultimately an online wine seller called Wine Library. He did this using social media and the power of the internet. His message is about family, hard work, focus. Great businesses are not build in a month or two months or even a year. You have to do what you love, so you can work your ass off while the thing isn't making any money. If you don't love it, you won't have the energy to sustain it. This book gave me a few more ideas for connecting, and reinforced that patience really is a virtue.
What I Learned About Me
Over the last 8 months, I've been in a situation where I've had incentives to do the things that I used to do for free. I could go to a conference, show up and network, try to be smart and polished, and go home. The VersionOne brand hopefully benefitted, but past that... I didn't have any part of my compensation tied to how much software we sold. Sure, I had a paycheck, but at VersionOne, there wasn't any further incentive to go out and sell business. I trained people for a living... I blogged and networked and attended conferences, just for the love.
When those things became direct marketing activities, things that had an impact on how much money I make... they got uncomfortable. Now it wasn't about helping people, it was about finding leads, and seeing who I could impress. It was about making sure I got a business card so I could reach out to someone later, to maybe move some of our consulting services. It felt inauthentic. I struggled to find a way I could sell, that allowed me to keep my personal integrity. More than once I was called out because something about me was different, I wasn't being myself.
If I was going to do this for a living long term, I had to find a way to decouple psychologically, what I love doing, from how I earn a living doing what I love... at least from a direct financial perspective. What I found is that when these things were directly linked... it had a profound negative impact on my writing, my interactions with people, and how I fundamentally viewed the world around me. All in all, it hasn't been a healthy place for me to be. To be successful going forward, I had to think about things differently so I could continue to bring my whole self to my job. What I was doing, wasn't working.
I am fortunate that I love what I do, and I've found a way to make a living doing something that I deeply care about. It's not just about software development, it's about the quality of our human condition, it's about making work/life balance, it's about working in environments that make sense. It's about meaningful work, and creating real value. It's about putting people into systems where they can be successful. The methodology that surrounds that is just a means to an end... not a goal unto itself... no matter how interesting the technical details happen to be.
What I learned through some of these books, is that the stuff that really drives my passion, the stuff I love, is the stuff that I need to give away for free. It can't be tied to a sale. To maintain passion and enthusiasm for my craft, I have to contribute, I have to feel like I am making a difference, and I can't feel like every interaction is something to be monetized. I want to connect with people, in meaningful ways, that aren't always about selling someone something. I feel like the pending sale diminishes the quality of the relationship.
It makes me feel a little queasy and it's not who I want to be as a person.
Rethinking the Sale
I'm getting better at distilling what I like about this field and what has me excited to wake up in the morning. It's not the sale... it's not the chase... it's the connection. It's about helping people connect with each other. It's about helping people connect the dots in their organizations. It hit me a few months ago when I was doing this public class in Atlanta. We had 22 folks representing 12 companies. By the middle of the second day, they were talking to each other and exploring ideas and possibilities. I switched from teacher to facilitator and let the discussion play out. It was awesome.
I've decided that I don't want to sell. I want to help people be successful. I want to help people grow. I want to connect them to each other and to the community. I'm going to bring my whole self every day... try not to worry about quotas and revenue. I have to trust that if I do all the right things, and work really hard, the rest will follow. Integrity is about being internally congruent. What I'm really doing is, I'm learning how to sell with integrity, in a way where I can live with myself.... and do what I love as a result.
I don't know that I have the details worked out yet.. but this feels like the right way to think about things. I feel like I've gotten myself finally on the right path.
It's About Context, People!
In any given situation, there are a ton of things that could possibly work. One of the most successful projects I ever managed was delivered using a mix of Waterfall, Agile, and RUP. We had a existing product that our customer wanted to enhance. The customer knew exactly what they wanted and never changed their mind. The teams involved had built the original product, and they knew the code like the back of their hand.
We used a big-up-front-design, traditional estimating, and Gantt charts... even on the agile side. We did 'black box' the agile teams, but they had to inspect and adapt their way into the overall project plan. We delivered the project on the promised due date, within something like 1% of the original cost estimated, and with everything the customer had originally asked for. My company made the money they expected to make and our client made the money they expected to make.
We didn't do a death march, there were no 11th hour surprises, the deployment went exactly as expected.
Scrum is an empirical process control method. When you have a high degree of variability, and predictive planning methods are likely to fail, empirical process control can help manage and constrain the chaos and complexity, and optimize your project outcomes. It's a more expensive way of managing project outcomes, but works better when variability is high. If variability is not high, and the system is well known... it's possible Scrum is not the best choice, even on a software project.
I think part of our problem right now is that we've somehow decided that Scrum is the way to go no matter what the project characteristics. We get so enamored with the benefits the team gets from adopting Scrum, sometimes we forget that Scrum might not be well suited to the business needs of the enterprise. That's not a knock on Scrum... it's just that Scrum might not be the best tool for the job. It is up to us as organizational and project leaders to understand our options.
Thursday, June 10, 2010
The Gist of My Agile Dev Practices Talk
I know this is really high level... but I want to see what kinds of questions this level of description generates. Does it make sense? I'm really trying to figure out how to explain some of these ideas with fewer words.
2. Scaling scrum works under certain condition, if it scales... do it.
3. Scrum requires significant transformation for most organizations.
4. People underestimate what it really means to transform.
5. Transformation is too disruptive for many companies, these people will fail.
6. We need a credible transition strategy for everyone else.
If you are an 'everyone else', go read my last post... I'll wait.
7. Define a static organization model.
8. Find the constrained capability, create an agile team there.
9. Do agile for a while with that team, do it again with a few others.
10. Define your first agile multi-team project. Use expand and collapse Kanban, across teams, to limit WIP.
11. Define your next few multi-team agile projects, now you have a portfolio. Use expand and collapse Kanban, to limit projects in progress (PIP?), and manage WIP across teams.
12. Define capabilities outside of IT... extend agile to them.
13. Wash, rinse, and repeat
Key Concepts:
1. Scrum will break in complex product organizations.
2. Use a Static Organizational Models as the basis for agile pilots.
3. Use Lean and Kanban to intentionally limit WIP at the project level and the team level.
In general the talk was well received. A handful of people walked out... maybe this wasn't what they expected, maybe they just needed to use the restroom ;-) A few folks challenged the ideas I presented... Bob Galen and I had a follow-up conversation. More than a handful stayed after, talked to me in the hallway, and took business cards.
This is not everyone's problem... but if it's your problem, you need to go into your agile transformation with your eyes wide open... and some credible strategies for incrementally adopting agile.