Written by Mike Cottmeyer Saturday, 12 June 2010 02:34
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.Join the conversation. There are currently 8 comments.
Written by Mike Cottmeyer Saturday, 12 June 2010 12:57
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.Join the conversation. There is currently 1 comment.
Written by Mike Cottmeyer Friday, 11 June 2010 03:07
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.Join the conversation. There are currently 4 comments.
Written by Mike Cottmeyer Friday, 11 June 2010 03:40
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
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.
Written by Mike Cottmeyer Friday, 11 June 2010 12:17
Okay… I want to make an assertion here. In order for agile to work, you’ve got to understand the static organizational model for your company. Why? If you are organizing around things that are transient, like projects, you are doomed to fail. Agile requires teams that stay together, period.
Most organizations are organized around one static model, the resource team. This is our much beloved organizational pattern where we pull all the BA’s into one group and all the developers into another group. People are assigned to project teams, but the resource organization is the strong side of the matrix, the project organization is the weak side. Resource teams don’t deliver value by themselves.
Agile asks us to organize around the parts of the business that deliver value, and in common practice, that is usually the product. It makes sense, we make products, let’s organize around the stuff we make. This is where we get the whole, give the team what they need to deliver, and they’ll give you working software at the end of every sprint routine. Single PO + Single Team = Delivered Business Value.
That works awesome in small product driven organizations. In the complex organizations we’ve been talking about here, this approach is problematic. Why? Investment is not always level across products. Sometimes I need a full staff and sometimes I don’t. Sometimes I want to improve one set of product capabilities and just keep the other capabilities in more of a steady state.
Uneven investment in products over time is what drives our obsession with project work. We know that we don’t need the same people doing the same thing all the time, so let’s deploy ‘teams’ to go build some value for us. When they’re done, we can break them up and have them go do something else. From an agile perspective, the problem is that this approach doesn’t keep teams together over time, and that makes it really hard to really do agile.
I’ll admit, you could create multi-disciplinary teams and run your project work through these static teams. This is on the right track, but still breaks down when the skills required project to project ebb and flow. I’m all for building teams around specializing generalists and bringing work to teams, but in complex organizations it is a stretch that every team is going to have every skill they need to do every project.
So… back to our static organizational model. If we are going to keep teams together, we need to organize the teams in our complex product organization around the things that aren’t likely to change over time. We need a static model for the organization that is resilient. One that reflects the core delivery capabilities of the enterprise, capabilities that can be staffed and deployed to solve specific business problems
In our complex product example, the delivery capabilities might be the various products delivered by the organization. The services they provide to external customers, or to other internal products, become the capability the organizations is expecting them to deliver. A capability could also be something like marketing, or sales, or support, or even some external service provider that you depend on for a fully functional product.
Before you begin your agile transformation, you need to think about your organizational structure. Ask yourself if you are building teams around stuff that will predestine them to be broken apart when the work is done. Are you piloting something that has no chance of long term successes when it get’s out into the wild? It is important to understand what the non-transient, static model for your enterprise looks like, first.
Then, and only then, should you decide where to pilot your first agile team.Join the conversation. There are currently 6 comments.
June 17-18 Alpharetta, GA
No scheduled events.