Scaling Agile Past the Team – Agile Dev Practices Edition
Written by Mike Cottmeyer Wednesday, 9 June 2010 09:43
If you guys have been following my updates here and on Twitter, you know that I’m out at Agile Development Practices in Vegas this week. I’m speaking in about an hour… and just putting the final touches on my presentation. The content is not fundamentally new, I think though I’m learning how to talk about this stuff better. So… here is the slide deck I plan to go live with. Have fun, and let me know if you have a group that would be interested in this topic. Depending on your schedule and mine, I might be able to come out and do the talk for you live and in person!
Interesting Post… 6/1/2010 through 6/6/2010
Written by Mike Cottmeyer Monday, 7 June 2010 01:40
Twitter search won’t seem to give me any of my tweets from before 6/1 today, so this installment of Interesting Post… is going to a be a little short this week. Hope you enjoy…
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
Real Men of Agile Genius Sweepstakes http://bit.ly/9AnaMY
Agile Scrum, Or Not-So-Agile Scrum? http://bit.ly/aPpbam
Is this noise inside my head bothering you? http://bit.ly/bjVgt8
Kanban and Conversations http://bit.ly/ahdSUd
Big Pie in the Sky… And Other Stuff!
Written by Mike Cottmeyer Sunday, 6 June 2010 02:44
Time has been absolutely flying by the past few weeks. Lot’s going on here in Atlanta, some of which I want to share with you guys this evening. First of all… I’ve got to tell you about the place we went to dinner tonight.
Big Pie in the Sky
The challenge was for two people to eat a 30 inch, 11 pound all-meat pizza in under an hour. Needless to say… that was out of our league. We did order the 30 inch, 11 pound all-meat pizza, but it took seven of us to put a dent in it. We still came home with leftovers. The kids got a kick out of driving across town to eat at a place we saw on TV. It was really fun… and definitely out of the ordinary.
ATdL100
I got a great invitation to attend an executive networking meeting last week called Atlanta TechDev Leaders (ATdL100). Van Williams, my former SVP at CheckFree/Fiserv was the host, and put together an excellent panel to talk about Innovation. It was really cool hearing these senior leaders talk about what factors contribute to innovation in their companies. More often than not I heard colocation, collaboration, and iteration. If I didn’t know better I would have thought I was at an agile meet-up.
Dan Pink – Drive, The Surprising Truth About What Motivates Us
I’ve been doing quite a bit of reading the past few weeks. This one I actually downloaded from Audible.com and listened to on my iPhone. This is a game changing book, and a must read for anyone that needs to get the best out of their team. The main takeaway from the book is that knowledge workers tend to be intrinsically motivated, the are more inclined to perform for the sheer joy of the work. Offering extrinsic rewards often results in lower performance and gets us exactly the behavior we don’t want. Again… a must read
Seth Godin – Linchpin, Are You Indispensable?
I don’t even know where to start with this one. First, excellent book. Next, go read it. Godin starts off talking about how our schools and our society are setup to get people to conform. He explains how the old social contracts, the ones that rewarded conformity with lifelong employment, are no longer in place. Workers are doing their part, but the security that we used to have in return is no longer there. Godin makes a strong case that successful people are those that make themselves indispensable. Success comes from giving, being part of communities, and shipping.
Chris Anderson – Free, Future of a Radical Price
This is the one I am reading right now. The book explores the economics of the Free economy… from open source software to illegal song downloads. It’s another one that challenges conventional wisdom and shows you how to make money by giving stuff away. The general premise… remember I’m only just starting… is that as the cost of delivery goes down, it is almost impossible to make money from the distribution of information. Give the ideas away for free and make money off of something else. Again, a very powerful and very radical idea. Somewhat counter-intuitive.
Pillar Southeast
We’ve spent a bunch of time and energy investing in relationships with a few dozen companies here in the Atlanta area. That investment is starting to pay off, and we are beginning to sell some business here in the region. I love this new gig, but the sales cycle for some of these deals has taken much longer that I ever thought. It is really nice to start seeing the other side… the light at the end of the tunnel you might say. I love getting out and helping people, and I’m excited to be on the ground working with clients on a more regular basis.
Kanban Training
Dennis Stevens and I just wrapped up the first ever Kanban course in Atlanta. We had an excellent group of people… almost 20… attend the class. The class went very well and everyone learned a lot. I think some of us get desensitized to how fast new ideas are emerging from our community. Many people are still just hearing about Kanban… if they’ve heard anything about it at all. It is cool to introduce people to such new and powerful ideas for the first time. It is very rewarding to see that light go on as people discover that there ARE solutions to some of these problems they have been wrestling with for so long.
COHAA Conference
A week or so ago, I was up in Columbus, Ohio… reprising my Agile PMP talk for 350 (or so) agile practitioners. The Central Ohio Agile Association did a great job organizing the conference and I really, really enjoyed hearing Ken Schwaber, Michael Mah, Patrick Wilson-Welsh, and Isreal Gat speak. It was one of the first conferences in while that I actually went to attend sessions and learn. It was interesting hearing Ken Schwaber’s take in the new Scrum.org group. Ken had quite a few great lines… but one of the things I really respected was when he said ‘whatever we do will be wrong… but we have to do something’. I can live with that.
Agile Development Practices West
I’m heading to Vegas next week to do my talk on Scaling Agile past the team. This talk is really about applying Scrum (and Lean and Kanban) to manage agile delivery in complex product organizations. My thinking on this has gotten clearer over the past few months, so I am putting some effort this weekend into refactoring my slide deck. I speak on Wednesday and am tied up Monday and Tuesday… so I better get busy. If push comes to shove, I can always fall back to the original presentation.
Agile 2010
Lowell Lindstrom asked me to produce the Enterprise Agility stage… this was first for me and quite a good experience. I also had my talk on scaling the product owner role on large complex products selected, so I’m happy I’ll get to speak too. It’s funny, I think the material in my scaling agile talk, and my talk on product ownership in the large, are starting to converge. There are a couple of core themes that keep coming out. I think they are really important and stuff that our community needs to understand… so I’m geeked. That said, I’m bummed we had to move from Nashville, but Orlando is always an excellent place to have a conference… and of course it will be fun to see old friends!
Lee Copeland was gracious enough to allow me to do my Scaling Agile talk in Orlando too. Again, I think this is a strong message that people need to hear. I am happy to have a forum to spread the word.
Raising Boys
As my kids get older, I am constantly amazed watching them grow. My oldest turned 14 this year. He is a great kid, plays percussion in the marching band, and is a straight A student. That said, he is pushing his boundaries and trying figure out his limits with his Mom and me. A few weeks ago, he got busted making out with his girlfriend in the dugout at the high-school. It was totally awesome watching the consequences come down from the school system, and seeing him learn a lesson that I didn’t have to impose. I love watching these guys grow up… totally awesome!
Stephen King – Wizard and Glass
If you follow me on Twitter, you may have caught that I am slowly working my way through Stephen King’s Gunslinger series. I just finished the 4th in the series called Wizard and Glass. I wasn’t sure what I thought of it as I was working my way through, but now that it is done, I think it was probably my favorite of the four so far. I’ve decided to take a few weeks off before I start reading book 5.
Scout camp coming up
Last but not least…after Agile Dev West, I’ll be up in Gainesville, GA at Scoutland chaperoning 10 teenage boys at Summer Camp for the week. Once we are done, Zach should be a Life Scout and Daniel should be a Star Scout. I am personally looking forward to a relatively relaxing week. I plan to take that time to get going on our book again. I am anxious to get back into the habit of writing daily, I really miss it. It has been tough being creative when there is literally no space in my life.
All good stuff… just freakin’ busy! If you made it this far, thanks for coming along for the ride!
Trustworthiness… Then Trust
Written by Mike Cottmeyer Friday, 21 May 2010 01:21
Trust is an import part of what makes agile really work. It is so important, we are intentional about creating the opportunity for that trust to emerge within the team. We are intentional about creating a planning, delivery, and feedback cadence that helps trust form between the team and the business. Trust is a fundamental precondition to how we write requirements, how we estimate, and how we assess progress. Without trust, agile isn’t really very agile.
But what do you do if you are in an organization where trust is really low? What if you are working in an organization with a long history of distrust between the development team and the business… an organization where the business has unrealistic expectations and a perception that development never gets anything done. You might decide to adopt agile, but that history isn’t going to go away overnight. In this case, is it fair to ask the business to trust the team?
One of the biggest complaints I hear from new agile teams, is that the business does not trust them to deliver. They are convinced that all their problems would go away if the business would just trust them to do their jobs. These teams want the business to trust them first. The problem is that the business has no history of getting what they want. They have no history of software being delivered on time. They have no history of getting the quality they need to be successful with their customers.
If you are a team that wants to be trusted, I would suggest that you stop asking the business to trust you. When you frame the problem this way, it makes you powerless to do anything about it. Either the business changes or you can’t be successful… the problem is beyond your ability to influence. What you need to do is become trustworthy. Becoming trustworthy is something that you have power to do something about. If you are trustworthy long enough, you will earn the trust of the business and won’t have to ask for it.
Subordinating the Scrum Team
Written by Mike Cottmeyer Monday, 17 May 2010 01:01
Agilists intuitively get that it’s a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That’s a big part of why we document agile requirements as user stories… we want the placeholder now, but we don’t need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.
Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can’t be validated. Everything that we define now, everything that can’t be built and tested immediately after specification, represents something that we’ll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.
Furthermore, requirements gathering an analysis shouldn’t be done in a vacuum. We know that we’re going to want some help from our development team to discuss what’s possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It’s a pretty solid formula for going slower than we have to.
Even though we may have some capacity to do the requirements work… and it would be nice to get ahead of the game a little… it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we’d gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.
We understand… in this kind of a scenario… that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.
Now, let’s extend this metaphor up a little and talk about our financial services company… and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization… our Scrum team is able to produce working software much faster than everyone else around them. The question we’re dealing with is… SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I’m saying no.
I’m suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.
When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won’t be ready to build for another several months. All that code will slow us down and make us resistant to change.
While it is technically possible for the Credit Card Processing team to get a head of the game… and it might make them feel more productive… it might be great for their team morale… ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So… for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.
It’s counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.
Join the conversation. There is currently 1 comment.