Written by Mike Cottmeyer Sunday, 25 October 2009 12:18
It started this year with the Agile 2009 conference in Chicago and is going to wrap up mid-November with the Agile Development Practices conference in Orlando. Between now and Orlando, I am heading to Boston to speak at VersionOne’s Agilepalooza. This will be my second Agilepalooza and these are really excellent events. After Boston I am heading to Malmo, Sweden for Oredev 2009. This is my first year speaking at an Oredev conference, and my first trip to Sweden, so I am pretty excited. My wife gets to come along for that one so it will almost be like a little vacation! After I get back from Sweden I turn right back around and go to Orlando for Agile Development Practice to reprise my Agile PMP talk.
My goal this year was to reuse as much content as possible so I wouldn’t have to be building so many new decks. Last year everything I did was brand new and I thought I was going to die! Anyway… I’ve gotten a lot of mileage on the Agile PMP deck and even managed to create a little new content along the way. By the way… if you are ever interested in having me come out and speak… let me know… we might be able to work something out. Here are the abstracts for all of my upcoming talks as well as my updated bio.
Agile Adoption and Scaling – Agilepalooza Boston and Oredev 2009
Agile methodologies are helping teams deliver software faster and with much higher quality than ever before. Given the success of agile at the team level, many managers are exploring the possibility of implementing these methodologies across the entire product delivery organization. These managers launch their adoption efforts only to uncover many common myths, misperceptions, and obstacles that derail their efforts before they really get started.
Organizations fail to become agile because they don’t understand what makes agile teams work. Breaking past traditional organizational constraints, even the constraints imposed by some of the better known agile methodologies, will free managers to create situationally specific strategies that support the formation of teams and enable them to deliver both reliably and consistently back to the business. Agile teams become the building blocks of agile organizations.
This talk will explore a roadmap for agile adoption that begins with teams and demonstrates how teams work together to deliver more complex projects and portfolios. Mike will expand the team concept to include capabilities and show how capabilities can be organized to optimize value across the enterprise value stream. At each step of the adoption process, Mike will demonstrate how to choose the policies, practices, and metrics that create learning and drive sustainable organizational change.
Agile Adoption past the Team – Oredev 2009
Discussions of agile often assume that there is a single team, assigned to a single product, with a single dedicated customer guiding all the product decisions. In reality, many organizations are building complex products that require the efforts of more than one development team. When teams have to coordinate to deliver a highly integrated product, the product owner’s job often becomes too big for a single person.
Not all the interesting scalability problems are reserved for the enterprise. Product Owners have challenges when trying to coordinate the deliverables for only four or five dependent development teams. Quite a few organizations are expanding the role of Product Owner to include Product Owner Teams and Product Owner Teams with Architects. These teams work in partnership with the Product Owner to maintain the product backlog and drive integrated decision making.
This talk explores a 3 month coaching engagement where the customer needed to coordinate requirements and design across five highly dependent development teams. Mike will show how the teams went from zero to hyper-productivity in a matter of sprints by implementing solid engineering practices and deploying a Product Owner team to coordinate deliverables across the entire product delivery organization.
The Agile PMP: Teaching an Old Dog New Tricks – PMI IT&T SIG webinar, Agilepalooza Boston, Agile Development Practices, and the Agile Edmonton User Group
Agile methods emphasize trust, empowerment, and collaboration—moving us away from command and control project management to harness the passion, creativity, and enthusiasm of the team. In established organizations, success with agile practices hinges on how well traditional project managers adopt new ways of thinking about project structure and control. Building on the principles of the Project Management Body of Knowledge (PMBOK®), Mike explores how PMPs with experience in traditional development can adapt their styles and practices to become effective agile project leaders. Mike tackles the hidden assumptions behind the PMBOK and explores agile approaches for managing time, cost, and scope. Taking an in-depth look at PMI Processes and Knowledge areas, he also explores ways to adapt them to agile projects. Project managers, business analysts, and other stakeholders will leave with a new way of thinking about project management practices within the agile context and new tools for delivering value in the face of uncertainty.
Mike Cottmeyer is the Vice-President and General Manager of Pillar Technology Southeast. Pillar Technology is the leading provider of agile transformation services helping companies develop the technical practices and leadership competencies required for sustainable organizational change.
Prior to joining Pillar, Mike was an agile consultant, coach, and evangelist for VersionOne. Before VersionOne, Mike was a senior project manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has 20 years of experience leading IT initiatives using a combination of traditional, agile, and lean project management best practices.
Mike is a certified PMP Project Manager and a certified ScrumMaster. He co-created the DSDM Agile Project Leader certification and holds Foundation, Practitioner, and Examiner level certificates. Mike is an honorary member of the DSDM Consortium, a founder of the Lean Software and Systems Consortium, and helping lead the AgilePMI Community of Practice.
Mike speaks internationally on the topic of Agile Project Management and writes for several blogs including http://www.leadingagile.com
Written by Mike Cottmeyer Sunday, 25 October 2009 12:07
Okay… so the hard reality is that these aren’t going to happen every week. Actually… I suspect that this might be my last ‘Interesting Post…’ summary for the next couple of weeks. I’m getting ready to head off for two weeks straight travel so I might be lucky to get even a regular blog post or two out while I am gone. As you guys know… traveling can be hit or miss with me. Sometimes I get out there and am inspired… sometimes traveling wears me out. No idea how this trip will play out Anyway… more on my travel schedule and upcoming speaking engagements in the next post… for now it is time for another installment of ‘Interesting Post…’
Kanban Drives Culture and Organizational Maturity Changes http://bit.ly/2P2Fnd
Switching stories mid sprint http://bit.ly/jcVJm
How to Give Yourself to Whatever the Moment Brings, and Forget Stress http://bit.ly/40uZB1
Scale in London http://bit.ly/4aFeZn
Self-Organization vs. Evolution http://bit.ly/2tbkqC
The Agile Playground #2 http://bit.ly/Y3cnV
Standard work in Agile development http://bit.ly/WXhgz
Why You Should Know What You’re About http://bit.ly/1MIIyw
The effect of adding new people to project teams http://bit.ly/1avU1K
Scrum, Bikram Yoga and The Attention Economy http://bit.ly/2L6YqL
Challenges with Daily Stand-ups… http://bit.ly/1pXAp1
Why Project Managers Fail http://bit.ly/123wAk
Is Kanban A Relabeling of Scrum? http://bit.ly/17y2hO
The Real Project Shrink. http://bit.ly/POgxy
Agile Business Service Management http://bit.ly/11ZIHI
Why Should You Care About Social Media? http://bit.ly/qBsaK
Humans Don’t Scale http://bit.ly/W2shj
PMBOK v4 and Agile mappings http://bit.ly/29lLPi
Solution Verification and Validation http://bit.ly/MgDlV
Agile is treating another disease http://bit.ly/1p8URWJoin the conversation.
Written by Mike Cottmeyer Saturday, 24 October 2009 12:19
Before we start talking about an alternative to velocity, let’s take a moment to recap the last few posts in this series… I’ve basically stated that velocity only works in certain circumstances and in certain types of organizational structures. For velocity to work as advertised… first, the organization has to be totally feature driven. Every team has to work on a complete end-to-end slice of user functionality. Second, the teams have to be totally nested underneath the project in a many-to-one relationship. If teams are supporting multiple projects, team level velocity isn’t meaningful at the project level.
What’s interesting is that most companies have a really hard time achieving this ideal structure even within the technology organization. At this point, we haven’t even considered the parts of the business outside of product development. What about sales… what about marketing… what about accounts receivable? In some form or fashion… these guys are responsible for getting the value out of the system too. Are these guys going to be nested underneath the project team hierarchy as well? I doubt it. So when we start looking at the enterprise value stream… velocity is almost a non-starter. The answer I believe lies in thinking about the collection of teams required to deliver a value feature much in the same way we look at the individuals on a single team. Let me explain.
A team is a collection of people necessary to deliver an end-to-end feature. You might have several developers… a BA… a tester or two… a customer… maybe an agile PM or a ScrumMaster. The team considers one or two small features at a time… they collectively negotiate the requirement and decide how the feature is going to be constructed. The team breaks the feature into tasks and the tasks are completed by the individual team members. They collaborate… they self-organize… they work together to make sure that all the parts come together in the form of a cohesive whole. The cohesive whole is then reviewed by the customer and accepted by the business.
The team always works on the highest priority features with the goal being to get to done as fast as possible. The team values finishing one feature before they start a new one. Team members help each other and balance the work because each team member has skills outside their primary area of specialization. There is an implicit understanding that there has to be some design before you can code… some code before you can test… some test before you deploy. Some of the steps are handled sequentially… some are handled in parallel. The team handles all that sequencing because the unit of work is small enough that they can handle it.
The measure of progress isn’t activity… it isn’t tasks on a plan… it is completed features.
Now… let’s build on the core concept of a small team working to deliver a discrete feature and explore how it could be applied to a team of teams working together to deliver a small project. The collection of teams is analogous to a collection of individuals… the small project is analogous to a single user story… releases are analogous to sprints… user stories are analogous to tasks. The teams get together at the beginning of a release to collaborate on the one or two small projects that they can deliver in the next three months or so… they break the project into user stories that are assigned to teams. Teams then deliver their individual pieces and work together to integrate those pieces into an integrated whole. The whole is accepted by the business and released to an external customer.
In this example we haven’t done away with velocity all together… each team can track its own individual velocity to help measure throughput and get more predictable. In this case though… the only meaningful velocity is the velocity of small projects that make their way through the overall system. Just like tasks and activity don’t measure progress at the team level… from a project perspective… team velocity is useful but not a measure of real project performance. The rate of delivery of small independent projects is the metric we really care about.
Hopefully this is all making sense so far. We haven’t solved the entire problem but this should give us a solid baseline for the next few posts. Hang in there… we’ll get through all this eventuallyJoin the conversation. There is currently 1 comment.
Written by Mike Cottmeyer Tuesday, 20 October 2009 11:07
Last week I did career day at my kids school. I can’t even manage to explain to my wife most days what I do for a living. What the heck was I thinking trying to explain my job to a room full of 8th graders? Do I talk about consulting and training? What about writing the book.. my blog… or all the social networking? What about all the meetings and travel and speaking at conferences? All of this is in some way related to how I make a living but really hard to explain to a room full of kids not old enough to get a part time job at McDonalds.
As I was thinking about it… the one thing that pretty much unifies everything I do is Software Project Management. That seemed like a pretty good angle so I went with it. Now that I had my hook… I found myself faced with a pretty substantial ethical dilemma. Do I really feel good about encouraging a room full of fresh-faced young people to go into the bone-crushing abyss that is Software Project Management? Do I really want to pave the way for my kid (who happened to be in one of my sessions) to consider Software Project Management as a viable career path?
Being a project manager… any kind of project manager… can be pretty life-sucking. You’ve got all this responsibility… no one usually works for you… you have to deliver a ‘fixed scope’ project where the scope is constantly changing. You only have so much money to spend and a team of people that are being pulled in a thousand different directions. You have to sometimes build fragile relationships with people you don’t really like… play a pretty brutal political game… and try not to piss anyone off so you still have a career the next time the business decides to do a major re-org.
It can suck being a Software Project Manager.
So I put together a few slides explaining all the cool stuff that I’ve done in my career. I talked about my book… my blog… and my Twitter and Facebook accounts. I talked a bit about traveling around helping other people learn how to do Project Management better. Since no one really knew what Project Management even was… I anchored it to things like science fair experiments and building tree forts. I talked about managing time, cost, scope, and risk. I talked about the thrill of delivery and the pressure that comes with trying to make everything work. I was candid too about the parts that aren’t so fun like being responsible for outcomes when people don’t actually work for you.
I mean… I am pretty realistic about what I might have been able to accomplish, but I think I was able to explain my job in a way that wasn’t totally boring. The biggest thing though I wanted to get across… the one thing that tied all the social networking and blogging and speaking back to Software Project Management… was that these kids are responsible for creating their own opportunities in life. They might not create their opportunities the same way I created my opportunities… but they are responsible for making things happen. They can be in charge and choose their own path. And for the record… I love being a Software Project Manager… it’s just that some days… I can’t quite figure out why
When my son got home later that afternoon, I asked him if he got any feedback from his friends and if they like the presentation. He told me that compared to the next person I was awesome. Then I made the mistake of asking what the next person did for a living… she sold Mary Kay cosmetics. Oh well!Join the conversation.
Written by Mike Cottmeyer Monday, 19 October 2009 11:21
Lot’s of companies are finding out about velocity the hard way. There are many, many contexts where velocity just can’t be used effectively to measure enterprise throughput. These companies are doing some interesting things with velocity in an attempt to compensate for organizational structures that are just not setup to be really agile. These organizations start tracking individual velocity… they start mapping points to hours… they start planning sprints in advance… they start mapping dependencies to try to get some level of predictability. They start doing predictive, plan-driven project management under the guise of agile.
These organizations might be delivering software incrementally… which of course is better than one big-bang delivery at the end… but they are not able to really inspect and adapt… they are not able to do lightweight planning… they are not able to do lightweight artifacts. They are not able to keep the cost of change low… and we know that when the cost of change is isn’t low… we get resistant to change… and being resistant to change is the antithesis of agile. So… it is a pretty interesting dilemma… and we need an answer.
We want to be able to use velocity at the enterprise level, but at the end of the day… our projects and portfolios… our teams and our organizations are not setup properly to be able to make velocity a meaningful measurement. Recognizing the problem is the first step toward defining some meaningful alternatives… the next step is defining some meaningful alternatives . No matter what we come up with… we have to accept the fact that much of what we are reading in the agile literature is not going to work without some sort of measured, planned adaptation. Scrum (by the book) isn’t going to work unless you can transform your organization overnight… and in most companies… that probably isn’t going to happen. Here are a few approaches I have used with varying degrees of success:
Only Build Software with 6-8 People
Believe it or not… this is the answer that lots of people come up with. Why bother to solve the scaling problem at all? Let’s just have small teams take over the world of software development. Let’s never build anything big or enterprise class. Sure… small always makes things easier… but it is definitely going to limit the size of the problems we’ll be able to solve. And somehow this just feels like we are punting on the problem. Maybe we just forget about the rest of the organization and get really good delivering what we can control? We just pretend we are small when the enterprise around us is really big. That works great until you realize your team is doing awesome but the enterprise can’t deliver anything of value. Any guarantee that your team won’t be the ones to go at the next round of layoffs?
Totally Restructure the Organization
We could tell the leadership of our organizations that we have to move to a nested feature team model. For that model to work… we need to get to a place where we have total test coverage, true shared code ownership, we’d have to be comfortable that any developer could touch any part of the system, and we’d have to let go of any sense of having a unifying architectural vision. After all… Enterprise Class Systems Architecture just emerges… right? We’d need to have a solid commitment to building teams around specializing generalist and trust that no solution would ever require any meaningfully specific domain knowledge to build out the product. Everybody gets to do everything.
It wouldn’t be trivial, but I think you might be able to pull off this approach transforming a 50-60 person organization. I maintain though… at some size… at some level of scale… taking the nested feature team approach is going to become unmanageable.
Combine Velocity and Traditional Project Planning
This is a more honest approach than trying to force velocity to work when the conditions necessary for it to work are not in place. Rather than bend velocity into something it isn’t by mapping points to hours… or tracking velocity at the individual level… go ahead and concede that enterprise velocity just isn’t going to work in your company. I would rather see a project manager use high-level Gantt charts at the portfolio level and use velocity and burn-down at the team level. The teams can use velocity to forecast and make higher level project commitments.
The project schedule is created by the project manager using team-based velocity data. The key is to update the project schedule… iteration over iteration… as the team builds and learns about the emerging product. The schedule becomes a high-level roadmap that governs where we all need to be and when. Just like an high-level architectural vision can guide and constrain the solution, the high-level project schedule will guide and constrain our iteration objectives. At the end of the day… it is really never the Gantt chart that is the problem anyway… it’s the attitude that the Gantt chart is Gospel that causes problems. Used appropriately and at the right level of abstraction… the Gantt chart can be an okay tool for solving this enterprise integration problem.
Abandon Velocity all Together (Almost)
The solution is going to take more than a few paragraphs to explain… but I want to touch on a few high level ideas before we wrap. The answer to the velocity problem is going to be found by looking outside the boundaries of traditional agile approaches and building in some of the principles and practices that seem to be just outside mainstream agile. We are going to need Lean… we are going to need Kanban… we are going to need the Theory of Constraints. We are going to need to think differently about how we select and approve project and how we are going to build our project portfolios. We are going to have to make smaller bets and build systems in smaller chunks. We need to start focusing on the flow of value that LEAVES the organization rather than the “value” we create INSIDE the organization.
We’ll explore some of these ideas over the next couple of posts.Join the conversation.
Upcoming Training Classes
2-Day ScrumAlliance CourseCertified ScrumMaster(Sold Out)
December 2-3 Orlando, FL
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep
December 5-6 Alpharetta, GA
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep (Sold Out)
December 9-10 Washington, DC
2-Day ScrumAlliance CourseCertified ScrumMaster
December 12-13 Alpharetta, GA
2-Day ScrumAlliance CourseCertified ScrumMaster
December 16-17 Washington, DC
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep
December 19-20 Westminster, CO
2-Day ScrumAlliance CourseCertified ScrumMaster
February 20-21 Alpharetta, GA