Interesting Post… 8/30/2009 through 9/5/2009

Written by Mike Cottmeyer Sunday, 6 September 2009 12:44

Agile 2009 and PMI http://bit.ly/fuPNS

The Big Agile Persona

Written by Mike Cottmeyer Saturday, 5 September 2009 01:15

A little about our intended audience…

When Dennis and I started thinking about our book, we told the publisher that we’d really like to write for CxO crowd. We want to be able to influence the people that can really effect change in a meaningful way. We want to give them the tools… the language… and thinking patterns to successfully start transforming their organizations toward a more agile way of building software.

The reality… many CxOs are not going to pick up our book… and after really thinking about it… that’s not where a book like this is going to have the most impact. We need to write for the mid-level manager who has direct influence over their organization and is able to evangelize these ideas to their peers and their leadership team. We want to enable folks to act locally… but think globally. The book needs to be tactical enough to help the guys doing it and visionary enough to influence the key decision makers outside the team and up the organization.

Armed with that new bit of insight… we decided to take a page out of Jeff Patton’s handbook and create a persona for the manager we think might want to read our book. We also created a profile for the target company our persona might work for. We wanted to have a really clear idea of the problems our manager was trying to solve and the resistance they might have to overcome in the process.

So like everything I’ve talked about the past week or so about framing this book… this is ALL subject to change. We just wanted to have a starting place for the conversation.

Frank Michaels, Development Manager

Frank is 34 years old and married with two young children. He has a bachelors degree in Computer Science from the local state university and is currently making just under 100K per year. Frank joined his company a little over four years ago as a senior developer. He is considered by his manager to be someone with excellent technical skills… an open mind… and has consistently demonstrated his ability to get things done.

After only a year, Frank was asked to serve as team lead and was recently promoted to be the team’s manager. With this recent promotion, Frank has several teams under his control and more direct interaction with the other managers in his department. He coordinates with the other functional managers to drive work through the organization. He works closely with various project managers to assign resources and track project deliverables.

Frank is frustrated by the whole corporate thing and really questions his decision to become a manager. He spends way too much time in meetings and just isn’t interested in all the corporate politics. It takes over a year to bring a new release to market and it seems to be getting slower. Project schedules are unpredictable and cost overruns are common. To make things even worse, quality has been suffering as pressure to deliver has gone up.

StandardCorp’s Company Profile

StandardCorp is a public company that has been around for about 20 years. They grew organically for the first 10 or 15 years building software for the insurance industry. Several years ago the senior leadership team launched a strategy to grow through acquisition and they branched into the financial services sector. As of now StandardCorp is just under 5000 employees worldwide with most of their offices in North America. Product Development makes up about a third of their total employees.

As their product lines became more diverse, StandardCorp started looking for ways to leverage common infrastructure components and shared services as a way to reduce costs. The product teams began looking for ways to combine product offerings to create competitive differentiators in the marketplace. Several initiatives spun up to rationalize architectural model but these initiatives have been expensive and success has been sporadic. In fact, these initiatives have slowed down time to market and made products harder and more complicated to deliver.

Product Managers are frustrated because they used to have total ownership of the requirements and the technical teams they needed to deliver features to their customers. As the organization has grown, the delivery model has become more complex and it takes forever to get anything to market. In frustration, the product teams specify larger and larger initiatives in an attempt to get competitive feature sets to market. In response to this inability to deliver… the organization has decided to grow up. In the past year StandardCorp has made significant investment in CMMi, ITIL, and PMI Project Management as a means to get more predictable business outcomes.

Costs are going up… market share and revenue are going down. StandardCorp has already started offshoring some of their development activities and it looks like more offshoring and more layoffs are on the way.

Acknowledgments

Before we wrap, I’d like to give a special thanks to my wife Kimi. She was gracious enough to do some research for me while I was away at Agile 2009. I asked her to find information on about 10 different mid-level manager roles in a typical software development organization. She found information on Project Managers and VPs and lots of roles in between.

Interestingly enough… there were lots of similarities and overlap in terms of age, marital status, gender, and even salary. She gave me names of folks she found with links back to their original sources. Funny thing was, she actually gave me some links back to people I knew in the industry. Anyway… her research was really helpful… so I just wanted to give a nice pubic “THANK YOU” for helping me out. Thanks Kimi!

Noodling on Kanban… Part Four

Written by Mike Cottmeyer Friday, 4 September 2009 12:19

Okay… time to wrap this thing up. If you missed any of the first three ‘Noodling on Kanban‘ posts… I included links at the bottom of this one… just to make it easy on you guys

There is clearly much more to this topic than I wanted to try and address in this tiny little series. We could talk about how Kanban drives culture… how it gives managers a role… how it is more inclusive. Karl Scotland and I debated over Drum-Buffer-Rope and how it applied to Goldratt’s Boy Scout story over drinks at Agile 2009. We agreed we were splitting hairs. I tried to get David Anderson to admit that Kanban was just a visual way of managing and elevating constraints… he didn’t agree.

There is lots more to say… but for the general agilist or newbie… this should be enough to start. For this post we’ll wrap with some of my thoughts on what situations a Kanban might be particularly useful and what I see for Kanban outside the team. To me that is the much more interesting problem.

Time to Use Kanban?

My personal take is that Kanban… even Kanban with a capital ‘K’… is not a development methodology. It is not a replacement for Scrum or XP or AUP or DSDM. I do think that Kanban is a powerful tool that can be used when some of our more common agile practices stop making sense. Consider these examples:

Have you ever tried to talk about planning in two week iterations with a team that is responsible for production support? The idea that you can’t add anything to the sprint once it is started is going to fail… we’d probably abort every sprint. How about a mature product team that is iterating an existing product? Does it necessarily make sense to stop every two weeks for a few hours to plan… to retrospect? If requirements are generally understood… the team talks over lunch… and they just know how to get things done… probably not.

How about a team that suffers from late delivery in the sprint? A Kanban board can keep them focused on continuously delivering value… even if they don’t do away with the iteration boundaries. What about a new team that isn’t ready to self-organize or self-manage? A Kanban can give the manager a tool to help the team learn how to self-organize and self-manage. We can use Kanban as a replacement for stuff we don’t need or as an addition when we need a little bit more control. Something to consider, huh?

Kanban in the Enterprise

Personally, I find most problems at the team level pretty uninteresting. It’s not that team level practices aren’t important… they are incredibly important… it’s just that most of the teams I work with have environmental problems. If the organization would just create the team… leave the team together… let them stabilize… let them establish a pattern of delivery… most of the coaching stuff we do could work itself out. Coaches could focus on helping competent teams become excellent.

Similarly… at the team level… Scrum… Kanban… who really cares… let the team decide what works for them and go for it.

For me… Kanban gets really interesting at the portfolio level and across the enterprise value stream. Most organizations really struggle to get value flowing in a predicable way out of their enterprise project portfolios. What if we could have an enterprise Kanban… a portfolio Kanban… a project Kanban… and a team Kanban. As you go deeper into the organizational hierarchy… the work in process limits at the enterprise level force value from the portfolio… portfolio limits force value from the projects… and projects force value from the teams. Imagine a system with enterprise cycle time all the way down to team level cycle time.

Thinking about the enterprise as a series of capabilities… capabilities that together form a system… a system that can be managed and subordinated to the constraint… now that is exciting. Now we can focus our enterprise agile adoption dollars at the constrained teams and resource groups to get maximum value from our investment dollars. That is where I’d like to see us to start talking about Kanban.

Hope you enjoyed this series of posts. Make sure to comment if you think I’ve got this all wrong… I am open to your feedback. Oh… and here are the links for your reference:

Noodling on Kanban… Part 1
Noodling on Kanban… Part 2
Noodling on Kanban… Part 3

Noodling on Kanban… Part Three

Written by Mike Cottmeyer Thursday, 3 September 2009 06:40

Earlier today we noodled on the secret sauce… maybe even THE most important value add… of implementing a Kanban system. Kanban gives us a very visual way of identifying and elevating the constraints in our system. The ONLY way to really get a team to go faster is to increase capacity at the constrained steps in the development process. Building inventory in other parts of the system leads to waste and re-work.

If you get nothing else out of this little series… that is your take-away.

For today… we are going to talk about going iterationless. So far we haven’t really talked about the iteration but most Kanban teams have figured out how to live without them. We’ll talk a bit about how to measure progress without being able to measure velocity at iteration boundaries. Without iterations… without velocity… we need another measure of team throughput…. and that is where cycle time comes in.

Going Iterationless

While agile is fundamentally designed to accommodate change, the idea of an iteration implies some degree of certainty about what it is you plan to build, even if that certainty is only two to four weeks into the future. In some environments customers can’t wait until the iteration boundary to introduce changes. In some environments requirements cannot be neatly fit into a consistently sized window of time.

This understanding has led some teams to abandon the iteration all together and now consider planning at iteration boundaries to be a wasteful activity. These teams have opted toward working directly from the prioritized product backlog and only bringing new work to the team when the work in process limits allow a new feature to begin. Agile introduced the idea of small batch sizes by limiting the amount of work that could be pulled into the iteration. Kanban teams take this approach to the extreme and reduce the batch size at any one time to that of a single user story.

Teams that implement this approach have ad-hoc planning meetings when the team is ready for new work. They conduct periodic operational reviews to asses team performance, communicate with management, and evaluate the overall health of the system. Teams choose appropriate boundaries for traditional retrospectives but they are not necessarily tied to the operational review or any predetermined time-box.

Velocity versus Cycle Time

Agile teams become predictable by stabilizing the size of the product backlog and establishing a consistent velocity over time. We can assess the delivery date of a fixed scope product backlog by dividing its total size by the velocity of the team. Likewise, we can use velocity to make trade-off decisions when trying to manage to a fixed delivery date release. Without the iteration, there is no longer a fixed period of time from which the team can measure team velocity.

Kanban teams replace velocity with the notion of cycle time. Cycle time measures the total elapsed time from when the feature was started until it is marked complete and accepted by the customer. Cycle time can be useful for predicting delivery and making both short-term and long-term customer committments. Becuase features are independent and not allocated to a fixed scope sprint, the team can always work on the highest priorities of the business.

Many Kanban teams will track the cycle times of similarly sized stories, making a distinction between the cycle time of a one-point story versus the cycle time of the other possible story point values. If the team becomes proficient at breaking down user stories into similarly sized increments of work, estimation is no longer even necessary, and cycle time becomes the only metric necessary to measure the delivery capability of the team.

What’s Next

The next and final post in this series will talk a little about why you might want to choose Kanban and a bit about Corey Ladas‘ work on Scrumban… an interesting hybrid of Scrum and Kanban for teams in transition. We’ll also hit a little on some work I am doing with a couple clients to introducing Kanban boards for project/portfolio management.

Agile Chronicles has Moved!

Written by Mike Cottmeyer Thursday, 3 September 2009 03:36

Hey… most of you guys know that I write both here and at Agile Chronicles. But… did you know that I’m not the only one who writes for Agile Chronicles? We’ve got quite a few folks that post every now and again… and every one of them is worth reading. Here’s the deal… VersionOne upgraded our blog and we have a new look… a new URL… and a new RSS feed.