Some of you probably already get this… some of you might even disagree… but unless you are building software as a hobby… chances are, you building software for money. In other words, someone is paying you to write software for them.

Why would someone pay you money to show up and write software? They are paying you money to write software because they hope to sell that software and get even more money in return. It is an investment.

Ideally, we should want our investors to get a good return on that investment so they’ll keep investing. It’s our job as software professionals to help our sponsors get good, working software into the hands of paying customers as quickly as possible.  That’s how we make money.

The act of selling software funds our ability to build more software.

Conversely, our inability to sell software makes investors grumpy and a lot less likely to want to keep paying you to write software. Unless we sell software, we don’t have any money to pay people to build software.

To many, the thought that we are writing software for money cheapens our craft… it cheapens our art. We want to be pure. We want to build perfect products. We want to perfect our craft and be artisans.

Don’t get me wrong, I’m all for building great products. That said, at some point, we have to strike a balance between perfection and getting products to market, products that can sell and start generating revenue.

Why am I writing this post?

Over the past few years, I’ve worked with a bunch of folks that have seem to have lost this fundamental connection to the economics of software development. Some where along the way, software became and end unto itself.

…somewhere along the way it became more important to be great engineers.

…somewhere along the way it became more important to be great testers.

…somewhere along the way the design became more important than the delivery.

Some where along the way, it became more important to deliver everything at one time rather than to getting something into the hands of our customers as quickly as possible. I think that mindset is killing many of our companies.

If you were spending your own money to build software, you’d want to see a return on that investment as quickly as possible. As software professionals, we have to start thinking about the economics of software delivery and act accordingly.  How would be build software if our own money was at risk and failure wasn’t an option?

Related Posts:

• Is Quality an Absolute?
• The Problem with Precision
• Sharing Risk With The Team
• Lightweight Documentation… Not Lightweight Thinking
• Working Software or Customer Value

This got published today… here is a link to the interview:

 

 

 

 

 

 

 

 

 

http://www.infoq.com/interviews/Mike-Cottmeyer-Agile-Adoption-Transformation

Take a look and tell me what you think.  Here is just a little more about the talk:

Summary

In Agile, adoption and transformation are typically viewed as one big event. Mike Cottmeyer provides a holistic perspective that looks as adoption as the implementation of practices, and transformation along two dimensions, organizational and personal. Mike discusses how they are a means to an end, and how to avoid the trap of focusing on practice adoption as a goal.

Bio Mike Cottmeyer is a PMP Project Manager, an Agile Certified Practitioner (PMI-ACP), and a Certified ScrumMaster. As an Agile Coach Mike provides mixed-methodology Agile Training, Agile Coaching, and Enterprise Agile Transformation Services designed to help pragmatically, incrementally, and safely introduce Agile methods into any sized organization.

About the conference The Agile Alliance organizes the Agile series conference, which bring together all the key people in the Agile space to talk about techniques and technologies, attitudes and policies, research and experience, and the management and development sides of agile software development. Related Posts:

• Speaking at SQE Agile Dev Practices… West
• The Agile PMP on InfoQ
• 10 Questions with Mike Cottmeyer
• Mike Cottmeyer… DZone Interview at Agile 2009
• Southern Fried Agile Conference… It’s Gravy for your Brain!

 

 

We just wanted to take a moment to wish you and yours a very Merry Christmas.  Hope you’re having a great day surrounded by the people you love!

- Mike, Dennis & Peter

 

Related Posts:

• InfoQ Interview with Mike Cottmeyer – Agile Adoption and Transformation
• New Agile Content Aggregator: BlogNotions
• LeadingAgile Welcomes Dennis Stevens and Peter Saddington
• Happy New Year 2011!
• TAG Product Management Talk

Intentional. One of my favorite words as of late… and a theme I am constantly preaching to my clients. Mirriam-Webster defines intentional as being done by intention or design. Dictionary.com defines intentional as being done with intention or on purpose. Google suggests several synonyms for intentional including deliberate, willful, or purposeful. Intentionality implies we have thought things through, we have chosen a course of action, and we are willing to accept the consequences of those actions.

If we are going to succeed, we don’t want to succeed by accident. If we are going to fail, we don’t want to fail because we didn’t have a well thought-out plan of attack. Intentionality means that we have a clear line of sight between our activities and our outcomes. That’s not to say our intentions are always going to be right… our intentionality might not yield the outcomes we hoped for. If we are intentional though, we can understand what we did wrong, learn from it, and do something differently next time.

My oldest son is turning 16 in a few months. Zach is a great kid, but like any teenager he has his moments. One day he was giving me crap over something he didn’t think I was doing right. That day he felt compelled to share with me what he thought of a few decisions I had recently made. I told him that in no way did I think I was a perfect father, but also that I have always been very intentional with him. Almost every aspect of his life, good or bad, was as result of an intentional decision made by me or his Mom.

I think that made an impression on him, I could see it in his eyes. Wait a minute, Dad has a plan!?

Many folks come into work and lead their organizations they have always been lead. They do the things the way they have aways been done. They get the outcomes they always get because no one is intentional about changing things. No one is intentional about understanding the way we do things today, and understanding how a few intentional changes might make things better. Even introducing agile into an organization, we do things by the book. We fail by the book too… with no understanding of what might have gone wrong.

There are tons of things we can choose to do that will help us become great organizations. There are even more things we can choose to do that will almost certainly to lead to failure. Whichever path we choose to go down, intentionality makes all the difference. Decide a course of action, create shared understanding, and create a shared sense of purpose. Work together toward common goals. Succeed together because you had a plan to succeed…

… and what if that plan doesn’t work out the way you wanted?  Learn from your mistakes and be intentional about what you are going to try next.

Related Posts:

• Feelings, Thoughts, and Actions
• E is for Estimable
• The Real Reason We Estimate
• Trustworthiness… Then Trust
• Scrum Gathering Agile Architecture Talk

I think engineers are interesting people… especially software engineers. Given what I do for a living, I get to work with a lot of software companies, and that means I get to spend time with a lot of software engineers. If you spend enough time, in enough software companies, with enough software engineers, some patterns start to emerge.

One of the patterns that I see quite a bit is that software engineers like things to be really precise. Being precise is a good quality for software engineers… it helps them build software that doesn’t break. Sometimes broken software kills people. The problem with being precise, is that it sometimes creates a tendency to want to know everything before we are willing to do anything.

Sometimes the level of precision necessary to build a system isn’t the same level of precision necessary to understand requirements, or to do a high-level design, or to estimate a project, or to know when a system is going to be done. Sometimes directionally correct is good enough. I realize that knowing the difference is a big deal and I’m not minimizing that.

I think though that recognizing this tendency is an important first step to making progress… and not letting that innate need for precision prevent us from taking those first critical steps forward. For many problems… understanding the requirements, or the design, or the estimate, or the date in a directionally correct way is good enough.

Once we get close enough, we can make trade-offs to the requirements, or the design, or the estimate, or even the date to make sure we can deliver what needs to be delivered. Precision isn’t always necessary to start… sometimes directionally correct is good enough.  Sometimes directionally correct is all we’ve got, and maybe even all we are ever going to have.

Related Posts:

• A Few Thoughts on the Economics of Software Product Development
• Lightweight Documentation… Not Lightweight Thinking
• Balance the System First
• One Real-Life Product Owner Team
• Limiting Work in Process… Are There Any Other Options?

The Scrum Product Owner has a tough job. Translating business strategy into product strategy and ultimately into teeny-tiny user stories takes a ton of time and effort. Most Product Managers don’t have the time or inclination to be a good Product Owner and most Business Analysts, the people most likely to fill the gap, don’t actually own the product. I almost always recommend to my clients that a team of people work together to fill this role. I don’t really care about the whole ‘single wringable neck’ thing… all I want is well groomed prioritized product backlog, and I think there is more than one way we can get there.

Here is the deal… when teams can’t get well groomed product backlog, it is almost impossible to do Scrum. Teams spend too much time figuring out what to build during sprint planning and not enough time figuring out how to build it. Because teams don’t know how to build the stories, they never really consider if the stories were estimable, nor really discuss how they could swarm to get the stories done earlier in the sprint. This will often result in teams of people that don’t work as teams, daily standup meetings that suck, and missed commitment after missed commitment. Not fun.

Anyway… as Kanban gains popularity and mindshare, many folks think that going iteration-less is the answer. If we can’t get user stories that are small enough to deliver a handful of them in a sprint, and we are always missing our sprint commitments, the problem must be with the time-box itself.  If the time-box has no value… it’s unnecessary…. it’s waste and needs to be eliminated. Maybe what we need to do is just take these big chunks of undefined requirements, run them through a Kanban, and just forget about splitting stories and managing iteration boundaries and totally avoid the issue altogether.

I’m all for eliminating waste, but let me ask you this… how does an iteration-less approach better help us know when we are going to be done?

Like it or not, this whole done thing is going to keep being a thorn in our side.  It’s not going to go away anytime soon. I think people are hardwired to want to know what they are going to get for their money before they agree to spend it. Some of us desperately want this to change, and maybe it will change as business models change, but for now we have to deal with it. I know, I know… if our customers would get out of the way, just let us code, and stop asking what they are going to get for their money, life would be a whole lot simpler.  I get it… it’s just not reality.  At least not my reality.

Okay, back to Kanban… Kanban can answer the ‘what are going to get for our investment’ question just as well as Scrum can. Scrum answers the done question by having us know the size of our backlog and the rate at which the team can complete that backlog, in other words, our velocity. When we know both of these variables we know what we are going to get, when we are going to get it, and we have a way to communicate project status. Kanban doesn’t use velocity, but instead measures cycle time and standard deviation to help us figure out what we can deliver and when.

In Kanban, we still have a queue of necessary features, but rather than measure our velocity sprint to sprint, we measure how long different sized stories take to complete and how much variation we have in that number over time… that’s cycle time and standard deviation. When we know the size of all the items in the backlog, and the normal variation of all the items in the backlog, we can use that data figure out when we are going to be done and what we can deliver in any given timeframe.  That’s good… there lot’s of ways to answer the done question… we just need one of them.

So, we’ve gotten rid of the time-box, but have we actually solved our problem with predictable delivery?  For Kanban to be predictable, we need know the rate at which we deliver requirements, and reduce the variability between the requirements over time. Let’s ask this though… if we don’t know really understand what it takes to build the requirements in our backlog, are we going to know our rate of delivery?  What about our standard deviation? It’s going to be all over the place.  Unless we know something about what we are building and how we are going to build it our delivery process won’t be any more predictable that if we were using Scrum.

I’d suggest that in both Kanban AND Scrum… to increase flow and reduce variation… we break things down into smaller more similarly sized and well understood work items.  In short, the same things that break Scrum are the same thing that breaks Kanban. And therein lies the problem… If we have to answer that pesky done question… we have to break things up small enough that we can tease out the risk and uncertainty, make fine grained trade-offs, and all get on the same page about what we are going to build. Kanban can solve lot’s of problems… and I believe we don’t even yet fully recognize the importance of David Anderson’s contribution… but here is my belief…

Kanban isn’t the answer to poor Product Ownership.

Kanban doesn’t fix anything if we don’t have someone to fill the PO role. We aren’t going to avoid this issue… we have to start figuring out who is going to step up to the plate, form a partnership with the development organization, and start really focusing on breaking stuff down into smaller pieces and driving that shared understanding I keep talking about. You can make the developers do it, but don’t be surprised when you don’t end up with what you expected, and run out of time and money before you have a viable product you can put into market. The inability to fill this role is killing us.

Related Posts:

• E is for Estimable
• Noodling on Kanban… Part Three
• Scrum or Kanban… it’s not Black or White
• Sharing Risk With The Team
• Velocity in the Enterprise, Part 6

I’ve been a big fan of Bill Wake’s INVEST model since I first learned about it through Mike Cohn’s book on user stories. Like every other agile blogger out there, I’ve shared my take on these principles and what they mean for product owners writing good agile requirements. The more I teach these concepts though, the more I find myself spending a little extra time talking about what it means for a story to be estimable.

On the surface, the notion of estimable seems pretty clear. In order for a story to be ready for a sprint, the team has to be able to determine what it’s going to take to build it. They have to be able to give an estimate. Why is the ability to put an estimate on the story so important? Well… if the team does’t know what the story is going to take to build, they don’t know if they can get it done by the end of the sprint.  If they don’t know how big it is, they can’t make a commitment to build it.

If the team cannot consistently make and meet commitments then velocity never stabilizes. When velocity isn’t stable, teams aren’t predictable delivering sprints. When teams aren’t predictable delivering sprints, we have no idea what we can deliver releases. When we don’t know what it takes to deliver a release, roadmaps fall apart and we have no ability to plan forward. In multi-team environments, this is catastrophic because the teams get out of sync and no one is able to deliver an integrated product.

But wait, we have an answer for fixing a story when a story is not estimateable… all we have to do is put in a spike! What’s a spike you ask? Usually I explain a spike as an investment the Product Owner makes to figure out exactly what needs to be built and how the team is going to build it. The Product Owner allocates a little bit of the teams capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.

In other words… its an investment to make the story estimable.

Here’s the deal with spikes though… spikes represent risk. Spikes represent uncertainty. If our backlog is full of spikes, that means that our backlog is full of stuff we don’t know how to do. If our backlog is full of stuff we don’t know how to do… that means that our product delivery process isn’t stable. It means that we have no business making commitments at the product level, or even at the release level, because we don’t have a credible plan for getting to done.

One of the things I’ve been talking a lot about lately with my clients… and plan to talk more about here over the next few months… is the idea that the only way to make better estimates, the only way to deliver releases on time and with a reasonable approximation of the scope expected… is to remove risk and uncertainty from what we are building. Removing risk and uncertainty involves doing one of two things: buffering for the unknown or mitigating risk ahead of time.

Buffering for the unknown is always a good idea… but mitigating risk and uncertainty is something that we don’t talk much about. If I want to reduce risk in a sprint, I pull some work forward to do the discovery before I am asked to make a commitment. If I want to reduce risk in a release, I pull some work forward to do the discovery before I am asked to make the commitment. If I want to reduce risk in a project, that means that I pull some work forward to do the discovery before I am asked to make a commitment.

All I’m really saying here is that we need to extend the spike metaphor beyond the level of user stories and sprints and up to the level of features, epics, releases, projects, and products. The more we need to be certain, the more we need to invest (no pun intended) up front to figure out how to build what it is we plan to build. Now, lest you think I am making the case for waterfall… all this is done in the context of small batches, doing just enough just in time, rolling wave planning, and progressive elaboration.

Agile methods accept the fact that some things are going to change… but that doesn’t mean EVERYTHING is going to change. I think it is fair for us to look far enough ahead to have some idea of where we are going, some idea of what we might want to build the next release, and some idea of the risks involved moving our product forward. Sometimes a little bit of planning, at the right level of abstraction, can help us make the case that we need to spend some time in this release getting ready for the next release.

At the end of the day, it all comes down to your context…

If you need to have a stable predictable product delivery process that can reliably look 6 months or so out… I think this kind of an approach is your only option, especially if your team is building a bunch of stuff they don’t know how to build. If your business is content figuring out your product strategy 2 weeks at a time… if a 4 to 6 week planning horizon is sufficient to make your customers happy… feel free to ignore this advice. Most Product Managers I talk to want  to commit at least a quarter out… most want 6 to 9 months.

Putting your product desires on a roadmap is not a strategy. Committing to things that you have no idea you can deliver is not a strategy. Asking the business to throw money at you on the promise we’ll do the best we can do and you’ll get what you get when the money runs out isn’t a strategy. Coming up with a credible plan, proactively mitigating risk, making trade-offs daily, and proactively managing your delivery is what makes your roadmap a reality.

So… next time you are committing to a sprint plan or a release plan… the next time you are laying out a product roadmap and making commitments to the business… ask yourself if the work is estimable. If it isn’t estimable, and you have no idea what it takes to get the work done, then you are assuming a ton of risk for yourself and asking your business to do the same.  In some contexts, some of the time, that is a perfectly fine strategy… just make sure you are intentional about what you are trying to accomplish.

If figuring it out as you go isn’t part of the plan… remember that E is for estimable and act accordingly. 

Related Posts:

• Kanban Isn’t the Answer to Bad Product Ownership
• Sharing Risk With The Team
• Some Thoughts on Agile Planning
• Product Owner Team… Who Needs to Play?
• How to Think About Estimating

As LeadingAgile nears its 400th blog post… it’s interesting to look back and see, not only how my writing has evolved and matured over the past 4 or 5 years, but also the kinds of topics I’ve chosen to write about. It’s an interesting study of what’s been important to me professionally and how my thinking on this stuff has emerged during this time.

I started LeadingAgile back when I was working for CheckFree, just before it was acquired by Fiserv. Like many folks that are heads down working in companies, it’s tough to write… not just because you have an all consuming day job and a family to raise, but because all your really interesting stories are about the people you work with everyday… you have to be careful.

It wasn’t until I started working for VersionOne that writing became a big part of my life. I remember talking with Ian Culling one day and realizing that blogging could actually be part of my day job. Not only did I have license to write, VersionOne provided a ready made audience for my work and allowed me a platform to really grow as an author. There are lot’s of things about VersionOne I am thankful for, and that was one of them.

Another great thing about VersionOne was having the privilege to work with somewhere around 100 companies over the two years I was there. It was fascinating to take my experiences as a company guy and vet them against so many different organizations in such a short period of time. It was like getting a lifetime of experience in just a few years. All of that experience really helped shape my views on what it takes to adopt agile practices and transform a company into an agile organization.

I’m not sure if I’ve ever explicitly stated this over the years I’ve been writing… but I’ve never really looked at my posts as a means to share what I know… they’ve been more a way to explore and share what I’m learning. Writing is a great way to sharpen your thinking and really helps refine and simplify your messaging. It’s the only way I know to teach yourself how to talk about this stuff. If you write your thoughts down they are in you. They are more readily available to share with others.

One of the themes that has emerged from my writing is that I seem to care less about how to solve problems and more about making sure we are solving the right problems. In large part, I am methodology agnostic. Of course I tend toward lighter weight agile methods, but I’ve never been a Scrum guy or an XP guy or a Kanban guy. I tend to be more pragmatic and open to using anything I can to make stuff work.

I find in my work that most people are solving the wrong problem or they are just thinking about the right problems the wrong way. Helping people solve the right problems and think about problems the right way is what I’m all about. It’s interesting to me how often my posts are more about trying to clearly articulate what’s wrong rather than offering some sort of solution. I’ve felt guilty about that over the years, but process isn’t rocket science. Figuring how to apply methodology to specific problems is much more interesting.

Another thing that’s been on my mind lately is the frequency with which I’m writing. I’ve been on the cusp of 400 posts for way too long now. The past few years have been pretty disruptive for me… not bad disruptive… but it’s been very difficult to get in a groove or to establish any kind of habits or patterns. For me, writing has to be a habit… it has to be a routine… and the demands of building a business have just blown that out of the water. Probably just an excuse, but something that’s been on my mind lately.

I’ve always written about the problems I was trying to solve and the kinds of thinking tools that I was using to solve them. It’s interesting, but my biggest challenges over the past two years haven’t been really related to agile. My biggest challenges have been around building a business and selling work. I’m actually surprised by how much I like that side of LeadingAgile, LLC. I love coaching and working with clients, but the organizational side of my own company is equally as compelling.

I been giving some thought to using LeadingAgile as a platform to write about some of the stuff I’ve learned over the past few years building a business and learning to sell. I’m not sure that writing about sales would be a great way to drum up new business, but I bet there might be some other coaches out there that might appreciate some candid lessons learned about selling work. Honestly, I don’t know, but that’s something I want to give serious consideration. Maybe I’ll just give it a shot and see what kind of reaction I get.

If you’ve made it this far into the post… thanks for sticking around. I’ve got a few more introspective posts I want to do before the end of the year. I’ve been meaning to write an appreciations post for a while now. I’ve been on an amazing run the past 18 months and I’m becoming ever more aware and ever more appreciative for the people that have helped me get here… I’m living the dream right now and I think there are some folks that deserve thanks for helping me along the way. I also plan to do my usual annual retrospective and talk about some of my plans for 2012.

Finally, I’ve been doing a bunch of consulting and teaching and thinking around this multi-tier program and portfolio management stuff and I’ve got to find a way to get some of these ideas on paper (electronic paper at least). I might be to the point where the components of this emerging approach are clear enough to talk about coherently. This is another thing where I just need to get off my ass and write. It won’t be perfect getting there, but then again… LeadingAgile has never been about publishing perfect thought.

Related Posts:

• On a Personal Note…
• Why Blog?
• 7 Tips to Get Started Blog Writing
• 2010 in Retrospective: Mike Cottmeyer Edition
• A Few Thoughts on the Economics of Software Product Development

Sometimes we get wrapped around the axle about estimating. People ask why we should bother estimating when we know that our estimates are always wrong. Some folks go so far as to say that all estimating is waste and we shouldn’t estimate anything ever.

A couple of posts ago I made the case that the real reason for estimating is to create shared understanding around what we are going to build and how we are going to build it. My point was that it wasn’t so much the number that was important, it was the process of getting to the number that was important.  You should check out the post, it generated a ton of great discussion.

While I still believe that estimating is primarily about creating shared understanding, I don’t think that post went far enough. Yes, we need shared understanding, but let’s get real… our customers need to know how much something is going to cost and when they are going to get it.

It all comes down to time and money… and what I am going to get for my time and money. What am I getting for my investment.

We’ve come a long way over the last 20 years understanding how to estimate. We seem to have learned that no amount of up front planning ever really makes better estimates. We seem to be getting better at deferring decisions and estimating closer to when the actual work will get completed.  All good stuff, but have our estimates really improved? Are we delivering on time and on budget more often?

Rather than give up on estimating, I want to introduce a new way of thinking about estimates. You see… we seem to think that an estimate is supposed to tell us exactly what it will take to deliver what’s being estimated. I believe that estimates are just supposed to get us close.  Estimates have to get us close enough that we have a shot. Once we are close enough to have a shot, we have to manage the hell out of the work to make the estimate real.

In other words, once we are close… estimates are no longer estimates… they are budgets.

Let’s say I bring a user story into a sprint and that user story is expected to take three points. Assuming we have a stable team, the team should have a general idea of how long a three point story will take to deliver. At the moment that three point user story is in the sprint… at the moment we have made the sprint commitment… we now have a three point budget to get it done.

With our three point budget in hand, it is now up to the team to work with the product owner to negotiate the implementation of the story to make it three points. It is up to the team to implement the simplest thing that could possibly work to make the story three points. It is up to the team to manage impediments and dependencies to make the story three points.

Delivering on time and on budget is not an accident… it is an act of will.  It’s a process of actively managing the implementation of whatever we are delivering to make the budget and schedule a reality.

Only at the point we learn our estimate wasn’t even close, only when we have learned that delivering something of value just isn’t possible, do we even get to consider slipping time or cost.  That said, if our budget was that far off, I’d say we have a bigger problem with how we estimated, how we generated shared understanding, and how we dealt with risk… but that is a series of discussions for another post.

Related Posts:

• The Real Reason We Estimate
• Who Owns the Risk?
• Selling Features We Don’t Have
• Stuck on Velocity…
• Traditional Estimating and Individual Accountability

Wanted to let you guys in on a little news… LeadingAgile is getting a little bigger.

Dennis Stevens and I have been collaborating for several years now and we’ve finally decided to create a formal partnership. Dennis has joined me under the LeadingAgile brand as a full partner in the company. While we were growing, we decided to pull in another premier Agile coach, who just happens to also be in the Atlanta area. Dennis and I welcome Peter Saddington (aka @agilescout) into the LeadingAgile family, also as a full partner.

Between the three of us, we have a broad and very complimentary set of skills and experiences. We are in the process of establishing the premier Agile consultancy in the Southeast. Pretty exiting stuff, huh?

Want more information about Mike, Dennis, or Peter?  Check out our bio pages:

About Mike Cottmeyer
About Dennis Stevens
About Peter Saddington

Related Posts:

• Merry Christmas from LeadingAgile
• Agile Atlanta in July… Dennis Stevens and Kanban!
• Southern Fried Agile Conference… It’s Gravy for your Brain!
• My, How the Times Are a Changin’
• PMI-ACP Certification Prep Course: October 17-19, 2011

I’ve been running around lately telling people that the presence of dependencies break Agile. Just for the record, I want to explain what I mean when I talk about dependencies. Agile in general, Scrum specifically, is predicated on the idea that the team has everything it needs to deliver an increment of value. When the team does not have everything it needs to deliver an increment of value we have a dependency.

Dependencies come in many forms. One of the most common is when the team needs some skill set that doesn’t live on the team. The classic example is the DBA that is shared across several teams or when QA is not part of the core Scrum team. Less obvious dependencies come about when the PO doesn’t have full discretion to make trade off decisions or when we have a UAT phase at the end delivery.

Why Dependencies Matter?

Dependencies matter because the secret to great team based agile is the accountability the team has to get done at the end of the sprint. If the team can’t get to done at the end of the sprint, or someone can undo done after the sprint is completed, it dilutes accountability and gives us an excuse not to deliver what we say we are going to deliver. It makes done beyond our control. It makes getting stable velocity beyond our control… it makes getting better beyond our control.

Sometimes teams will try to forcefully break dependencies by ‘empowering’ a PO that the organization doesn’t really view as empowered. Sometimes we’ll try to forcefully break dependencies by defining done in a way that the team is in control of what get’s delivered. That is fine from a team perspective, but doesn’t really solve the real problem of negative feedback loops and deliverables that aren’t ready to go into production.

Dependencies are Reality

But here is the deal… dependencies are real. Dependencies are especially real when we start dealing with Agile at scale. At scale we are not only talking about dependencies between the team and external entities, but between teams that need each other to deliver an end-to-end increment of working software. Our default thinking should be to reduce dependencies. A well thought out transformation strategy can help break many dependencies but we have to aggressively manage those that remain.

How we choose to manage dependencies makes all the difference to how we achieve real end-to-end business agility. If we implement agile teams but deal with dependencies through big up front release planning, we might not be any better off than with traditional project management approaches. Is there any difference between a Gantt chart and a multi-team backlog that is pre-sequenced sprint-to-sprint for the next several months? Here’s a hint, I can use Microsoft Project to model both.

Manage Constraints Rather than Dependencies

Agile at scale is typically described structurally as a hierarchy of teams that are loosely coupled from each other. Every team, at every level of the hierarchy, is an independent entity were velocity flows from the lower level teams to the higher level teams-of-teams. When we have dependencies between teams, this model breaks. The solution lies in the application of Lean Thinking and the Theory of Constraints, not at the team level, but across teams… both inside and outside of core product development.

The solution lies in the application of Kanban to model the flow of value across teams, to make smaller investment decisions at the portfolio level, to limit the amount of work in process, and to redeploy people and teams in ways where everyone all the time, is focusing on the highest value initiatives within the organization. We use agile at the team level to inspect and adapt and to make sure we are always focusing on delivering the most value possible in any given sprint. Using Lean and Kanban and TOC gives us that same ability when we are dealing with dependencies at any level of the organization.

Speaking at the PMI Global Congress

This is basically the subject of my talk at the PMI Global Congress tomorrow. If you happen to be at the Congress, I’d love to have you stop by. If you want an explanation of how to tactically manage through this kind of portfolio structure, check out this video I did a few months ago. I think it will help. Past that, if you are struggling adopting agile, chances are you have a dependency problem. Consider your current strategy for dealing with dependencies and if this kind of a model might help.

I bet it will.

Related Posts:

• Vanilla Scrum and Multi-Team Value Streams
• The Secret to Organizational Agility
• The Secret to Organizational Agility (Revisited)
• Reuse Creates Bottlenecks
• Why a Product Owner Team?

How far ahead should we plan? I depends on what you are building, when you need to have it done… and if you aren’t going to get done… how soon do you need to know about it. If your goal is to build the highest value features possible, deliver continuously to market, get real time feedback… you might be able to get away with planning a sprint or two out… maybe less. If your goal is to deliver a specific set of predefined features, all of which need to be done by the end of the quarter, you may want to have all three months laid out. It’s not that we wouldn’t inspect and adapt and deal with reality, it’s just that we need to know if our velocity isn’t trending such that everything is going to get done. If we don’t know how we are doing against done, we don’t know what tradeoffs we need to make along the way.

I’ve worked with several clients recently that were trying to operate as if the software they were building was emergent. It wasn’t. They were being asked to deliver a specific outcome, with a pre-defined set of time and cost constraints. For these guys, it was absolutely silly to only plan their backlog two weeks at a pop. They had no idea how they were doing against the expectations of the business. They had no idea if they were on track or not or how they should approach the business to negotiate scope trade-offs. They had no means to determine if their approach was trending toward and acceptable outcome. The reality was that they were going to work really hard, probably deliver a great working product, and still have their stakeholders upset with them.

Having a plan doesn’t mean that we have to have a death march. Having a plan means that we have a baseline to measure against. Some way to determine if we are making the progress necessary to achieve our goals. Remember that line in the Agile Manifesto? We value responding to change over following a plan?  While we value the items on the right, we value the items on the left more? The plan isn’t the problem… it’s failure to respond to change… to deal with reality that is the problem. If I have a fixed time, fixed cost, fixed scope project… I damn well better be delivering incrementally using an agile approach… it’s the only way of knowing if I’ve got a shot in hell of being successful. It’s the only way we can confidently let our stakeholders know if we are on track or not.

Not every team needs a project manager… but I think many could benefit from some really good project management. I’ve been an agile project management guy from the beginning, but I am becoming increasingly convinced that we need to be teaching teams, not just how to self-organize, but how to effectively manage delivery… product or project delivery, I don’t care which. Self organized teams need to have everything necessary to deliver an increment of value… it’s my opinion that everything necessary to deliver an increment of working product includes someone that knows how to manage risk, validate assumptions, communicate with stakeholders, assess progress against the goal, and know when things are off track. That can be the PO, the ScrumMaster, or someone else on the team… again, it doesn’t matter.

What matters is that project management is happening… no matter who does it.

Related Posts:

• Selling Features We Don’t Have
• Sharing Risk With The Team
• Some Thoughts on Agile Planning
• E is for Estimable
• Who Owns the Risk?