Scrum Gathering Las Vegas – Large Scale Program and Portfolio Management with Scrum
Last Updated on Thursday, 9 May 2013 04:52 Written by Mike Cottmeyer Wednesday, 8 May 2013 04:04
Hey everyone… I’m out in Vegas this week at the Scrum Gathering. Got invited to speak… which was really cool (thanks Daniel Gullo)… and did the most recent iteration of my Agile Program and Portfolio Management deck. Take a look and let me know what you think!Learn More
Projects Are Not The Problem
Last Updated on Wednesday, 3 April 2013 05:39 Written by Mike Cottmeyer Wednesday, 3 April 2013 05:38
A lot of folks in the agile community feel like projects and project managers are a big part of the problem we have delivering software. My view is that projects are not really the problem… it’s projectized organizations that are the problem.
Projectized organizations form when we have people organized into functional silos and assign them as necessary to project work. The underlying assumption is that people are fungible resources and can be split indefinitely across projects to get work done.
Agile methods take a different approach. People are organized into cross-functional teams and focused on a product… or a set of features… or a component… or a set of services… within the larger production ecosystem.
Projects as a funding vehicle in most organizations are just fine. The shift in thinking is that projects have to be broken up and funneled through teams. Each team is responsible for a subset of the project deliverables with integration happening on regular intervals
I’d much rather integrate the work of many teams producing working tested features than try to integrate the activities of many individuals working within their own particular speciality. Done is easier to see and bottlenecks are easier to identify and resolve.
This is the #1 biggest problem we see with organizations trying to adopt agile. They do not have a pattern for organizing teams and managing project deliverables across teams. Until this gets sorted out… you are not likely to have much success using agile at any scale.Learn More
LeadingAgile is Growing Again… Welcome Jann, Andrew, and Steve!
Last Updated on Sunday, 20 January 2013 01:06 Written by Mike Cottmeyer Sunday, 20 January 2013 01:06
Hey everyone… LeadingAgile growing again. It’s kinda crazy to think that just over a year ago LeadingAgile was a one man show. Now we have 9 consultants, a sales guy, two awesome back office support people, and four folks working almost full time as sub-contractors. The cool thing is that I don’t even think we are done yet. Just nuts.
Anyway… wanted to introduce you to the newest members of the team. They’ve all actually been on deck for a few weeks, but I’m just getting around to announcing them. We’ll get the website updated soon with permanent bios, but here is what I’ve got now.
Jann Thomas is a 20 year veteran of the software industry. She has worked as a developer, team lead and development manager leading teams to deliver great software. Jann has been practicing Agile development techniques in 1998 and implemented her first Agile Project in 2000.
She has a Project Manager Professional certification from the Project Management Institute, with a master’s degree in Computer Science.
In 2010 Jann delivered a 14 million dollar ecommerce replacement project with a 220 member team. The team including 95 developers working in a single codebase, pushed working code into productions every 6 weeks using an XP process. The entire 18 month project was 10% under budget, 10 % over functionality and 3 weeks later than initially planned.
Most recently Jann led a 12 person team through an agile transformation while continuing to deliver mission critical functionality. Pragmatically balancing process changes with functional development her team was able to complete features ahead of schedule and pick up high priority features from other teams.
In June 2004 she spoke at the International Conference on Software Process Improvement and In April 2008 she spoke at Software and System Quality Conference International. She was the Keynote speaker for Agile Bangalore in 2009 and spoke on Distributed Agile Delivery at Café Agil in Porto Alegre, Brazil. Jann is currently working as a Project Manager for Leading Agile in Atlanta.
Steve has over 17 years of industry experience as a developer, analyst, and leader at various levels. He has championed and successfully led agile adoptions across a wide spectrum of organizations, from the no-process chaos of a small startup, to the transition from a traditional waterfall methodology for a fortune 500 company.
Steve has focused his efforts on helping teams become hyper-productive by integrating agile processes with engineering practices such as continuous integration and test driven development.
He holds a Bachelor’s Degree in Computer Science, is a Certified Scrum Master and Product Owner, and is a Lean/Six Sigma Certified Green Belt.
In a former life Steve was a former Army Officer and paratrooper. When he’s not helping organizations navigate the agile waters, you will find him surfing with his family in his hometown of New Smyrna Beach, Florida.
Andrew Fuqua has been developing software professionally since the mid ’80s. Though it wasn’t called Agile back then, his first project used an iterative and incremental approach. After a few years of working in not-so-agile environments, Andrew began using eXtreme Programming in 1999.
Andrew is the current president of the Agile Atlanta user group, which he helped start in 2001. Andrew has held positions in management, product management and development at companies like Internet Security Systems, Allure Global, and IBM. Andrew earned a BS and MS in computer science and has an MBA from Duke University.
Please join me in welcoming Jann, Steve, and Andrew to the LeadingAgile family!Learn More
Prelude to a Series?
Last Updated on Monday, 31 December 2012 10:37 Written by Mike Cottmeyer Sunday, 30 December 2012 05:37
I’ve been pretty absent from the blogosphere the past year or so. I really do miss writing and often think about why I don’t write much anymore. It’s easy to blame it on being busy… but we are all busy. I think I’m beginning to understand things a bit better and can talk coherently about some of the root causes.
The first challenge for me is that I don’t have a lot of quiet in my life. By quiet, I don’t mean silence… I can find silence. It’s inner quiet that’s missing. There is always something going on, some problem to solve, or some issue to attend to. My brain is always off doing something urgent and urgent always seems to win.
The next challenge for me is that everything I want to say is just complicated. It’s not that the words are complicated or the ideas are complicated, it’s just that nothing running through my head stands alone. The problems we are solving are systems problems, not point solutions. Telling the story takes more time.
The last challenge is that I write to teach myself things. The fact that other folks may appreciate my work has always been an afterthought. So while yes, I am still learning, the stuff I’ve been learning about is hard to talk about on LeadingAgile. My world is much broader than it was even a year or so ago.
So… why tell you guys this?
I think I’ve created some space in my life for the next several months. I’ve got some stuff to talk about that is going to take me a little while to get out, but it’s important to me that these ideas get out in print. An finally, I think I need to learn how to tell this story better, so I am going to practice on LeadingAgile.
Prelude to a series maybe?
This series of sorts may start off slow… I’ve got a few foundational things I might have to get out before we can really get going. Yesterday’s post was one of them… how do you get people to hear you when maybe they don’t even want to be there in the first place? That is a foundational idea.
I think I want to explore some why I think so many folks are failing at agile even though we have proven time and time again that agile works. I hate to start the story here, but I think we may have some paradigm shifting that needs to happen before we can tell the rest of the story.
Once I tease some of these first thoughts out of my brain, I want to get down on paper how I tell the story. If you want to get right down to it, I want to tell the story like I would to a room full of executives that wanted to know what it looks like to do an agile transformation and what they get when they are done.
I don’t think any of us have done this on purpose, but I think there is a large part of the story that is missing and for many folks adopting agile practices, this absence is doing them a great disservice. I want to see if maybe we can uncover and talk about some of the secret sauce that makes this really work.
If all goes well, I plan to be writing in this space for the next few weeks or months. I may be saying this with the optimism of someone that just took a week off, and has a week off left to go, before the real world crashes back down on me… but like I said, something is different and I need to explore these ideas.
There are several major themes I want to hit… here they are in their expected order of appearance, but I make no promises this will hold:
1. What does an agile operational model look like? How do I do program and portfolio management? In other words, as an executive, how do I run an agile enterprise?
2. How do I take a deep look at where I am against the model and how do I decide what to improve so that I can get better at delivering an economic return for my company?
3. Once I know where I want to be, how do I plan to get there? Should I change everything all at once? Do I do things a piece at a time? What’s the change strategy look like?
4. How do I measure current state? What should I expect during the change? How do I begin to measure in the new model? How do I know I’m getting real benefit from my investment?
I’m sure there will be lot’s of little nuances and diversions along the way. I’ll probably say things I don’t mean but that are directionally correct. I may change my mind once I get two or three blog posts down the road. Maybe I’ll write a whitepaper once I have it all out.
Okay… done rambling for now. At least when I do posts on Sundays, most people don’t noticeLearn More
Getting Permission to Coach
Last Updated on Saturday, 29 December 2012 11:48 Written by Mike Cottmeyer Saturday, 29 December 2012 11:43
Ever walk into a room and feel like no one is listening? It absolutely drives me nuts. Sometimes it happens in a lecture hall, sometimes a classroom, the worst is when it happens in a small conference room full of people you are being paid to coach.
One of the things I’ve come to realize over the years is that no matter how credentialed your are, no matter what you know or how much you are getting paid, no one ever has to listen to you… you have to earn the right to be heard.
Because I have a severe aversion to wasting people’s time, I’ve developed a strategy of sorts that I’ve found to be pretty effective and generally repeatable in most situations where you’ve got to have permission before someone will hear you. The formula goes something like this…
Questions are interesting because they work on lots of levels. The most obvious is that you gain a ton of information and insight about how your audience understands their problem. Less obvious maybe is that good questions will demonstrate that you deeply understand your subject matter.
Good questions communicate a desire to understand and create a real opportunity to build trust and deeper connection. They help people feel heard and understood. People that feel heard and understood are generally more open to hearing what you have to say.
But here is the deal… you are not just asking any questions. You are using your expertise and understanding of common problems to dig into places where you are likely to find trouble. The goal will be to use what you’ve learned to setup the next phase of the conversation.
At some point you need to start transitioning into problem solving, but we still don’t have permission to tell anyone how to do anything. No one has asked for our help. There is a transition line I’ll often use here that seems to work. I’ll ask the room for permission to ‘explore some ideas’ with them.
We aren’t trying to solve their problem, but we may have earned the right to teach a little. It is much less threatening to discuss an idea than to go into the real issues. We can talk generically about how and why process works or how and why process fails, without having to tell them anything about themselves.
The trick though is that we must dynamically teach around the problem areas the group shared with you during the question phase. If they have a problem with product ownership, you should teach about Product Owners. If the group is having problems forming teams, explore how and why teams work.
Get The Ask
Hopefully, if all has gone well to this point, we’ve created a little cognitive dissonance. Cognitive dissonance is when people simultaneously hold two competing thoughts or ideas. The room should have a clear understanding of their current reality and a clear understanding of a possible vision for a future state.
The idea is to get people to the point where they want to have that cognitive dissonance resolved. It should be uncomfortable and prompt ‘The Ask’. ‘The Ask’ is when the room requests your advice on how to resolve the conflict. This is when you finally have permission to coach.
At this point, and only at this point, can you begin to start laying out specifics. Now we can start talking about how to solve their particular problems and help them work through their concerns. You can directly link their problems to the specific solutions and lay out a strategy for helping them get there.
Like any technique, you can use this kind of approach for good or for evil. To help or to manipulate. The goal in any coaching situation is to build trust, strengthen relationships, and genuinely find ways to help. To make it work, you have to really care, really listen, and create a real opportunity to connect.
I’ve used this approach with small delivery teams and rooms full of executives. It really works. People want to be heard, they want to learn, and if you can really listen to them and help them learn meaningful stuff, you just might be asked to help. Only when you’ve been asked to help do people tend to actually listen.Learn More