Books I Recommend Often…
Written by Mike Cottmeyer Sunday, 24 May 2009 12:35
Adam Lambert or Kanban… America Has Decided
Written by Mike Cottmeyer Wednesday, 20 May 2009 11:29
The American Idol season finale starts in a few minutes and I am really hoping that Adam Lambert pulls it out tonight…. that guy can really sing. Okay… okay… this is not a blog about American Idol… just had to get that off my chest. But in all seriousness… that is what I am planning to do with my evening… watch Adam Lambert take home the crown. Just had to pound out a quick post to get a few questions out into the blogosphere before the Adam Lambert victory party begins.
Addendum 5/21/2009: I was really bummed that Adam didn’t win… oh, well.
Throttling the Agile Enterprise
Written by Mike Cottmeyer Tuesday, 19 May 2009 07:35
It feels like a year ago I did the post Enterprise Constraints and Feedback. The past few weeks have been filled up with the Lean & Kanban conference and some client work that required my undivided attention. Toward the end of that post, we talked about 6 principles that allow your organization to properly throttle work through your agile enterprise. I wanted to take a moment this afternoon and explore those a bit and see where it takes us:
Make small bets by approving smaller projects
How many of you guys have been on an 18 month project? How many of you have been on an 18 month project that got killed or totally re-scoped after a year or so? The reality is that in today’s economy the uncertainty associated with large scale software development projects is just too high. The longer it takes to get product to market, to get real customer feedback, and to start generating revenue… the more risk you accept as an organization. Given our track record of project failure… smaller projects are less risky projects… and therefore better projects to approve.
Prioritize for finishing projects rather than starting projects
This is a complicated one. It gets into this whole discussion around keeping work in progress to a minimum and optimizing for the overall throughput of the organization… rather than for optimal resource utilization of the individual. If you are an agile organization, and have bought into the idea of organizing around teams, you should be pretty good with the idea of ‘done done’. ‘Done done’ means that we don’t deliver partially completed work. The only features that count are the ones that are ready to be shipped to the customer.
Interleaving a bunch of partially complete projects just makes the overall system deliver value less effectively. If we have three projects in the portfolio that are all planned to take three months each… and I do them one at a time… when will they be done? The first one will be done in three months, the second in six months, and the third in 9 months. What happens if I try to do all three at once? Best case you might deliver the first in 7 months, the second in 8 months, and the third in 9 months. More likely you’ll deliver the first one in 12 months and the other two will get killed.
Don’t start projects that you are unable to finish
Building on this idea of prioritizing for finish rather than start… if there is more than one team that has to work together to deliver a project… or even a MMF… and we can’t get all the work ‘done done’ within the time-frame allotted, don’t start it. We usually use some form of logic that goes something like… well, we have this person or this team with nothing to do… let’s get them working on the next project. Keeping people busy is not a good reason to start project work.
The problem is that starting the next project dilutes the organizational focus from working on the projects that are already in process. Chances are pretty good too that when the other teams free up requirements will have changed or we’ll learn something that leads to significant rework. This is tough pill to swallow… but I would rather that idle team go help another constrained team… or even do nothing… rather than start work on a project that is underfunded and low on the priority list.
Work on the highest priority projects first
All of these are pretty closely related, but if we always prioritize the project that is most valuable to the business… and we always focus on getting projects to ‘done done’… and we don’t waste effort by working on things that don’t have the support of the rest of the organization… we know that we will always be delivering the most valuable features to the business with the least amount of waste from building software that might not ever be consumed. This might mean that teams are idle at times… it might mean that teams need to be redeployed… and it might mean that you need to let some folks go.
Make sure to read the next section before you go and start laying folks off from your team… there is hope!
Provide support for those teams that are slowing down your ability to deliver
If you find that a large part of your organization isn’t busy because one particular team is slowing everyone else down… cool, you have just found where you need to go help. An enterprise full of teams building software is a continuously shifting set of constraints just waiting to be optimized. Someone at the Lean/Kanban conference said that a perfectly optimized organization has only one constraint optimized at a given time. An organization with every team optimized is actually the least optimized overall system.
Having identified the team that is slowing down your ability to deliver, you have identified where you need to go get better as an organization. By focusing your attention on the team that is preventing the other teams from delivering valuable work to the organization, you are focusing on the area of your development organization that is going to yield the most productivity gains for the overall system. It does not make any sense for a team to get better delivering software if they are not your primary constraint.
Establish an enterprise level velocity
If each team has a velocity sprint over sprint… and we start making smaller bets… and we prioritize for start… and we don’t start things we are not able to finish… and we start working on the highest priorities first… and we elevate our constraints… you know what happens? We can start measuring project velocity across the enterprise just like we measure point velocity within the team.
Pretty cool idea… let me know your thoughts on this one.
Join the conversation.ProductCamp Atlanta
Written by Mike Cottmeyer Tuesday, 19 May 2009 01:00
There is a FREE event for Product Management types in Atlanta. The first ProductCamp Atlanta will be held Saturday, June 6, 2009 at the GTRI Conference Center (250 14th Street, NW, Atlanta, GA). You can find the details here… http://barcamp.org/ProductCampAtlanta.
They are looking for sponsors and session leaders. (Product Manager types LOVE Agile topics). Please forward this post to other people who might able to come to Atlanta for the event. This is going to be really cool, I have done a few barcamp type events and they are great learning opportunities.
Right now I am a strong maybe to go… my wife and I are leaving for Vegas (SQE Better Software Conference) the week after so I don’t know what is going on with the kiddies that Saturday. If I were not travelling the week after… I would definately take a Saturday to go. I strongly encourage you guys to make this happen!
Join the conversation.Why a LeanSSC? Why a Lean Certification?
Written by Mike Cottmeyer Thursday, 14 May 2009 04:10
I wasn’t at the conference and so all I can do is read the press release. After reading I’m confused.
- Why does the world need a Lean Consortium?
- What does the Consortium hope to achieve?
- Why do we need another certification?
- How will this certification be different from the CSM/CSC/CST?
Confused in Ottawa
Mark
Hi Mark,
I don’t know that I’ll have all the answers here… the organization is brand new…. just barely out of concept… so some of this will shake out over the next few weeks. I can tell you the reason that I was interested in exploring creating a new organization.
As it stands right now, the DSDM Consortium and the Scrum Alliance are the only organizations offering certification. Very few people have heard of the DSDM certification and clearly the Scrum certification has exploded over the past few years. I like Scrum, I practice Scrum, and while not a CST… I teach Scrum. Scrum is a great small team framework but I do not believe that Scrum by itself is scalable.
Most of the teams that are scaling Scrum have expanded the idea of a single Product Owner to the idea of a Product Owner team. This is not part of base Scrum but is essential to coordinate the activities of many teams working in concert. Also, many large organizations are built around large system components, components that are products in themselves… these teams are building integrated systems within large component architectures. Scrum gives no guidance on how to do this.
In any organization that is large and complex enough for the feature team model to break down, you have to start looking for effective ways of managing flow across the organization… how to manage work in progress… how to manage constraints… how to manage dependencies. Scrum gives no guidance on these scaling issues… Lean does.
There were two primary camps in the room when the LeanSSC was formed. There were people that thought of Lean as a discipline unto itself… one with its own body of knowledge. The were also people in the room that felt strongly a LeanSSC needs to build on the foundation of agile, embrace what we know, but build lean scaling principles into the fabric of that body of knowledge. Personally, I am hoping the LeanSSC takes the latter approach.
So to answer your questions directly:
1. The world needs a LeanSSC because there is an agile body of knowledge that is bigger than what Scrum is prepared to address. By creating an organization that is broader than Scrum, one that can embrace a broader body of knowledge, we have the opportunity to engage academia, corporations, and individuals that are interested in advancing that body of knowledge.
2. Some of this will be worked out over the next few weeks but the general idea is to identify the body of knowledge, create a set of Lean/Agile competencies, and provide certification around these competencies. You might also imaging a structure that allows member organizations to contribute to and benefit from the growing collection of intellectual property. Ideally we create a very open system.
3. The Scrum certification has been great in leading the software industry to a broader knowledge of Scrum in particular and agile in general. Scrum as it stands now does not meet the needs of the enterprise… people that are making Scrum work in the enterprise are using techniques that are counter to Scrum and certainly not contained in the Scrum training material. The LeanSSC has the opportunity to broaden the certification track and give companies a path to build a more competent workforce. I can’t imagine that people believe Scrum is all you need to know to build large scale software projects.
4. I suspect it will be based on a set of published competencies. I suspect that there will be multiple training courses to address the various competencies. I suspect that any training organization will be able to deliver competency training and that to receive certification in a competency will require a test. I suspect there will be multiple paths through the competencies based on the objectives of the person or persons receiving the training (developer, manager, senior leader). This is not defined yet… but I suspect it will be a much more open system.
I would like to reiterate that this is all MY opinion and may not reflect the official position of the LeanSSC or any of the individual founders. There is a lot of work to do… the formation of the organization is just a first step.