Getting Started with Agile… Two of ‘Who Knows’
Last Updated on Thursday, 15 November 2012 01:03 Written by Mike Cottmeyer Friday, 19 March 2010 03:30
Okay… way too big a gap between meaningful blog posts. Since it has been so long, you might want to go back and take a look at the first post in this series called “Getting Started with Agile… One of Five“. There is a bit of irony here around how this post came to pass.
Personally, I am not prepared to believe that Scrum’s failure rate is because people don’t implement Scrum properly. That’s the whole Scrum-but argument. Scrum is such a light framework, if you give it a serious go, it’s pretty hard to really do it wrong. That said, I do believe that many organizations aren’t prepared to fix the organizational disfunction that Scrum is going to show them. Scrum’s primary benefit is that it shows you the stuff you need to fix. If you aren’t willing to fix the problems, you aren’t going to get the benefit.
How many companies using Scrum are really trying to transform the entire enterprise? I’d wager that most Scrum teams live within a larger, more traditional enterprise. In these organizations, structure and culture are going to trump anything that a single Scrum team does with people, process, or tools. You could have the best team members, run a perfect Scrum, have big visible charts everywhere, and I bet you still stand a chance of falling into Schwaber’s 75% statistic.
For everything we do to build a high-performing agile team, the organization is going to work to pull that team a part. The pull might be intentional, led by people that are threatened by any change to the status-qou. More than likely, the organization just doesn’t get it. The value delivered by the Scrum team just get’s lost within the larger underperforming organization. Even though the team was effective, it just never really translated to any kind of measurable value for the larger organization.
So therein lies the problem. What does it mean to have a successful Scrum team in an organization that isn’t performing very well? What do you do when Scrum helps you identify an impediment that can’t be solved by the team, but no one outside the team seems to care? Scrum ends up being a local optimization within the larger enterprise value stream. Unfortunately, it doesn’t matter how hyper-productive your team becomes… getting higher team velocity isn’t your biggest problem.
The trick to adopting agile is to form a team around a business problem the organization actually cares about solving… one that will increase bottom line performance. And this is where the conversation get’s interesting. Many of us aren’t responsible for improving the whole system. We are only empowered to do our part. We can only operate within our circle of concern. Our challenge is to figure out a way to make our local improvements, but in a way that is respectful of the whole.
There are a few things I want to suggest that will help you understand how your company looks at value delivery. For the rest of this post, I want to talk about aligning your agile pilot team to something your organization actually cares about. The important thing to realize is that not every company has the same kind of goals. If we are going hook ourselves up to big business problems, we need to understand how our companies look at value… how they look at the unit of production. For most, a unit of production is not a single user story delivered by a single team.
Adopting Agile Isn’t the Point
Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Thursday, 3 December 2009 03:01
I spent the first ten or so years of my career living in data centers. I was a network guy… built a lot of servers… installed a lot of operating systems. Before I made the jump into project management, my specialty was email systems… Lotus Notes in particular. The first couple of projects I ever officially managed were things like server upgrades and hardware refreshes. Sometimes we were doing upgrades just to stay current with the latest release… but most of the time, our stakeholders were investing money to get some new capability that was valuable to the business.
Usually I’d have a few guys on the team working with me. One of my pet peeves was when someone on our team would talk about our ‘server upgrade project’. From their point of view… we were upgrading servers. From the business’ point of view, we were investing in extra storage space so they could store more email messages or have more room for application data. Calling our project the ‘server upgrade project’ described what we were doing, but it didn’t adequately describe the value we were delivering to the business. It’s a subtle but meaningful difference.
When we allowed ourselves to define our work in terms of our activities, we risked losing focus on the desired outcomes of the project.
At the end of the day, the business didn’t care if we added hard drives, upgraded memory, or installed a new OS… they cared about the value that those activities would give them, and how that value would impact their ability to conduct business. They cared about the return on their investment… not how we got that return. I think there is a parallel here to how we think about our agile transformation projects. Are we adopting agile or are we getting feedback so we can build better products? Are we adopting agile or are we trying to get incremental revenue from our software development investment?
The goal is not to have Scrummasters and Product Owners. The goal is not to have cross-functional co-located teams. The goal is not continuous integration or pair programming or TDD. Those things are the stuff we do to get the desired business outcomes… those things are strategies that we believe will deliver the business value our organizations are investing to receive. Our challenge is not to mistake the proposed solution with the desired outcomes. There are LOTS of people that have Scrummasters and Product Owners that are not rapidly reducing risk… not getting fast feedback… not delivering incremental value… and not building an integrated end-to-end product.
Maybe this is just semantics… but I believe when we put all our focus HOW we think we are going to solve the problem… it is easy to lose sight of WHAT we were really trying to accomplish. It’s easy to start focusing on upgrading hard drives rather than the business outcomes those hard drives were purchased to deliver. Our goal is to stay brutally focused on business outcomes and choose strategies that we think will deliver those outcomes. We have to constantly inspect and adapt and be willing to change when we are not getting the outcomes we hoped for.
Because, at the end of the day… adopting agile was never really the point.Learn More
Adopting Agile… the Video Podcast
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Thursday, 20 August 2009 11:23
Agile Adoption and Scaling Patterns
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Wednesday, 19 August 2009 11:56
Over the past few months of writing Leading Agile… doing the Cutter Paper… and now preparing to write this book… we’ve talked a lot about different agile adoption and scaling patterns in the enterprise. Specifically here we’ve talked about team based agile, first order agile scaling, and second order agile scaling.
As Dennis and I have noodled around on this… talked to clients… implemented and consulted… and tried to build out this framework… I think we’ve landed on a five phase roadmap that can be talked about with some degree of clarity. We’ll go into detail on these over the next few weeks… but for now… I want to just put the model out there and see what you guys think:
Horizontal Scaling is the next step. As the name implies… horizontal scaling is taking the team based model and replicating it in different parts of the organization. We see this quite a bit… pockets of agility across the enterprise… but no one is really working together in a coordinated way. Pretty much the same as team based… just more of it.
First Order Agile Scaling is basically Agile Project Management. It is the first time we start talking about how to get multiple teams working together to deliver an integrated product or project deliverable. This is where we first start thinking about the various Scrum of Scrum patterns we talked about a few posts ago.
Second Order Agile Scaling takes a collection of teams from the single project space into agile portfolio management. How are we going to break up projects and throttle them through the teams? This is where we really start to focus on lean and TOC and have to focus on enterprise priorities and investment decisions.
Third Order Agile Scaling is an area we haven’t talked much about yet. This is where we take agile outside the product delivery organization. Getting projects out the door isn’t our problem anymore… it’s not our constraint. We need to start focusing on the integrating the value stream across the entire enterprise.
Why are you Failing with Agile?
Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Thursday, 2 July 2009 12:41
Okay… you’re a few months into your agile roll-out. You did all the right stuff before you got started. Got sign-off from the execs… check… got team members trained… check… identified a pilot project… check… hired an agile coach… check. Why then… after all this time, effort, and money… are we still struggling with the fundamentals? Why can’t we seem to get over the hump?
It seems that there is always someone… sometimes there are a lot of someones… that just don’t seem to get it. They just can’t let go of their trusted MRD… they can’t seem to get past the idea that agile teams don’t do Gantt charts. These folks want to know exactly when their project is going to be done… what it is going to cost… and what they are going to get for their money.
How do we respond to these people? Hey… agile can’t be any worse that what we are doing now? Agile is all about trust… you just need to trust that this new way of doing things is better. Just give us a few sprints and we’ll prove to you that this new way works. I promise, you’ll like it.
Put yourself in that other person’s shoes for a moment… your Product Manager was promoted and given big fat raises based on the insight and detailed analysis she put in those MR docs. The VP of Engineering got where he is today by making sure systems were designed fully up front. The Director of the PMO has built his entire career around applying the processes found in the PMBOK…not to mention the bonus he got for becoming a PMP in the first place.
These folks know something is broken… they know that we are making product development too hard…that is whey they let the team give this agile stuff a try in the first place. The problem is that… at the end of day… these folks are on the hook for making sure the organization delivers. When they are under pressure they fall back to what they know. They dance with the girl they came with.
It’s important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families… they have kids in college… they have financial obligations. You are not just asking them to change… you are asking them to put their livelihood at risk. People don’t resist change because they are bad people or because they just don’t get it. Chances are… at some level… they are afraid.
More than likely… there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful… and work to satisfy that need… on their terms… they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose… you’d probably do the same thing.
Trust me doesn’t cut it until you have earned that trust. Agile will help you get there… but you know what… you might have to let them have their Gantt chart… you might have to let them have their MRD… until you can make it safe for them to let it go.Learn More