I
got an interesting invitation to head to Malmo, Sweden this year for
the Oredev 2009 conference. I'll be doing two talks in the agile
track... one on scaling agile and the other an experience report based
on the coaching gig I did earlier this year. Regular readers will
recognize some of the topics I plan to speak about.
The Manager’s Guide to Agile Adoption
Are you going to be anywhere near San Francisco, CA on May 29th? You need to find a way to get to AgilePalooza.
AgilePalooza is the first of a series of not-for-profit community events presented by VersionOne. It is meant to be a fun, low cost gathering that brings internationally recognized coaches and trainers into community for a day of learning and advancing agile methods. None of the speakers are paid to present or participate...they are offering up their services simply to support the agile community. For the ridiculously low price of $69... attendees will get a full day of agile learning, breakfast, lunch and good times. If there are any funds left over after the event they will go directly back into the AgilePalooza program or be donated to the local agile user groups supporting AgilePalooza.
Go to http://www.agilepalooza.com for more information and to register. Where else can you get this kind of Agile love for only $69?
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.
May 29, 2009
Not very often does a speaking engagement like AgilePalooza stroll along where so many Agile All-Stars are available for an intimate session! Not only was I fortunate enough to hear about it, but I was also asked to speak on a topic that is very near and dear to me. I think we all feel that we either spend too much time meeting or the meetings we have been asked to have are becoming mundane and outdated. The content is not often what we would expect and often times the right participants are not presesnt..
The great news is there is an answer! There is a light at the end of the tunnel! As Agile is becoming more and more lean, the time teams spend together needs to become more and more valuable! My session at AgilePalooza will be focused on making meeting time more effective and meaningful. The description for the session reads:
“Facilitation Foundation”- Not Another Agile Meeting
Many teams struggle with the meaning behind or the value provided from attending Agile Meetings. This session is designed to help people better understand the logic behind Agile meeting patterns and is intended to present a new and more creative approach to meeting facilitation.
This session is geared towards both team members and product/project managers as well as any person who facilitates a session. Each participant will leave with a better understanding of why meetings fail or become painful and what they can put in their toolkit to help engage and bring added value to the meetings they attend or facilitate.
If you are out in the Bay area, I encourage you to attend! If you are not in the Bay area, keep your eyes peeled here as other locations are sure to be made available in the future! See you in SFO!
Here
I am.. Sunday afternoon.. Mother's day. Just got back from taking the
family out for a low key Mother's day celebration and now I've got a
little quiet time before the week begins. The conference last week was
quite a rush... had a great time... met a lot of great people. Before
the week gets going I want to sort through some of my thoughts on this
whole Lean/Kanban thing.
A bit of history... Mary Poppendieck
was one of the first few authors I ever read when I got formally
introduced into the agile community. I recall how much her book
resonated with me then... and looking back I can see how much it
influenced how I think about agile... and the agile movement as a
whole. I tell you guys that to say I have never made much of a
distinction between agile and lean. To me... it was just a different
way of looking at the same fundamental truth.
A buddy of mine
recently told me the story of the blind men and the elephant. The
general idea of the story is that we have a bunch of blind guys in a
room with an elephant (sounds like a problem waiting to happen to me).
These guys are each touching the elephant on different parts of its
body. The guy touching the tail says an elephant is like rope... the
guy touching its leg says the elephant is like a tree... the guy
touching its ear says it is like a giant leaf. You get the idea. The
point is that without being able to see the whole... they each describe
the elephant from their own particular point of view.
As I watch
people debate over what it means to be agile... it seems we were a
bunch of blind men arguing over the nature of the elephant. If your
point of view is small, colocated teams... scrum brings a valid
perspective. If your focus is more technical... the practices of XP
tend to resonate. If you come from a larger more structured
organization... you might need AUP or DSDM. If you have a really small
team of experienced developers... let's talk Crystal. Context is
everything.
It seems to me that much of our debate is out of
context. When we get dogmatic about one methodology... about one set of
practices... we are often not taking the other person's context into
consideration. That is why the Agile Manifesto was so powerful... it
was a set of value statements... it was a set of principles... that was
broad enough to be applied in a situationally specific way. We have to
take the local context into consideration.
I don't think the
Lean/Kanban proponents are saying they have found a better way... I
think that we are continuing to learn and to grow and to better
understand what it takes to deliver great software. It seems to me that
the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but
to help organizations that are having trouble adopting these
practices... or have adopted them and need something else to increase
their productivity.
Here is a quote from the Schwaber and Beedle book "Agile Software Development with Scrum"...
"Empirical
process control models are elegantly simple. They employ feedback
mechanisms to monitor and adapt to the unexpected, providing regularity
and predictability. The actors in a Scrum team empirically devise and
execute the best processes possible based on their skills, experience,
and the situation in which they find themselves"
The line
about the team devising the best processes possible based on their
slkills, experience, and the situation in which they find themselves
has always resonated with me. I think that Lean and Kanban give us
another set of processes and tools that can help the team improve. I do
not believe Lean and Kanban are at odds with Scrum... nor do I believe
that Lean and Kanban are going to be successful without the engineering
discipline encouraged by XP. We are just another set of blind men
looking at a different part of the elephant.
My personal take...
Kanban
is a visual process control tool that helps teams effectively manage
the flow of work through the sprint. Scrum gives guidance that the team
decides what they can do... and the team decides how it will get the
work done. Kanban gives the team another way to inspect and adapt and
to learn how to get better. I am not hung up on the fact that Kanban is
iterationless... I can apply it within the iteration. If I determine
that the iteration has become waste and no longer need it... I'll get
rid of it.
My goal has never been to do Scrum... my goal is to
build great software as fast as possible. In Scrum process improvement
is implicit... the team inspects and adapts and find ways to get
better. In Kanban we put specific visual controls in place that help
the team better understand the flow of work through the sprint and make
targeted improvements as necessary.
To me the idea of Lean is a
bit broader... lean deals with the enterprise. Lean is about managing
the flow of work across teams. How do I take an idea that comes from
biz dev... turn it into a product idea... get the work assessed and
approved... built... tested... delivered to the customer... billed...
and supported. Lean can give us some guidance here for how to manage
the flow of value through the organization. Kanban is a tool... Lean is
a philosophy.
A team could use a Kanban board to manage the
backlog item through the development phases... analysis, design, code,
and test. An enterprise could use Kanban board to manage the flow of an
idea from inception through development to billing and support. The
principles of Lean can be applied within the team and across the teams.
Understanding value streams... identiying constraints... eliminating
waste are all explicit ways of helping the team get better. These are
principles and tools that explicitly help the team inspect and adapt
and make better decisions.
As a founding member of the Lean
Software & Systems Consortium I hope we continue to build on what
is out there and resist the urge to make this something wholy new.
Remember... agile is all about uncovering better ways of developing
software by doing it and helping others do it.
Lean/Kanban gives us another set of tools to help that come about.
Last
post we talked about two facets of communication in the agile
enterprise... constraints and feedback. Constaints flow from the
higher levels in the organization... to give guidance... to constrain
the actions and decisions of the lower levels in the organization. At
the lower levels the agile teams are empowered to make decisions within
the context of the higher order constraints.
In my post Second Order Agile Scaling, I suggested that building teams around capabilities was the first step toward untangling our portfolio management mess. The second step... and equally as critical... involves having the discipline not to start projects we don't have the capacity to finish. We know from our experience with small team agile that writing requirements we can't develop is waste. The exact same thing goes for building capabilities that can't be consumed by the project team or the business.
Agile portfolio management involves identifying our most pressing business problems... or most lucrative market opportunities... and coordinating the capabilities of the organization to deliver the highest return on investment with the least amount of risk to the business. Our agile organization is going to organize around capabilities... understand and measure the throughput of each team... and focus on delivering the highest priority projects first.
Let's consider a simplified model for what this kind of project intake and decomposition might look like...
Figure 1 shows how a project is identified, broken down, and assigned to teams through progressive elaboration of the requirements and design
Here is the idea behind this diagram... the business is constantly looking for things to fix and opportunities to take advantage of... opportunities that will align with overall strategy and objectives of the enterprise. The business knows that these opportunities are going to leverage the combined capabilities of several teams within the organization... but early in the life of the project... we are not quite sure which ones. How do the strategic planners know what the organization can deliver... and when... so they know how to make commitments to customers?
The answer lies in progressive elaboration of requirements... the progressive elaboration of the solution architecture... while restraining our tendency to over-specify the solution too early. We need to make commitments... while keeping our options open... while we figure out the details. Let's look at this in a little more detail...
Circle 1: Strategy and Enterprise Architecture
When projects arise for consideration by the business... there must be a team in place that is responsible for assessing the set of possible business solutions (requirements) and the set of possible technical solutions (design). This teams job is to consider the objectives of the business to identify a high level solution that can be delivered within the time and cost constraints necessary to deliver the expected value with minimal risk to our investment.
See my post called Software Requirements Balancing Act for a little more around what I am talking about here. Putting this into more day to day terms... we need to identify the major epics and themes that will make up the product requirements. We also... and this is really important.. need to identify the organizational capabilities (feature teams, component teams, or services teams) that will be leveraged to deliver those high level requirements. In my mind... I call this enterprise architecture... the set of big block decisions that the organization makes to constrain the set of possible technology outcomes.
Circle 2: Product Management and Software Architecture
Once the business has decided what it wants to do... it needs to engage the capabilities of the organization to deliver. The themes and epics are assigned to the Product Owner team to break down into user stories. If there is a need to manage technical dependencies between component teams or services teams... this is where you begin to establish the high level software architecture. Admittedly... I'm not talking much about building software yet... but I fully expect this level of the organization to explore options... and validate decisions... by building out and delivering working code.
The goal at this stage of the planning process is to bring our understanding of the problem space and the solution space down to the next level of granularity. Just as the strategy team and the enterprise architecture team collaborate to keep the requirements and solution in balance... the Product Owner Team and the architect collaborate to keep the user stories and software architecture in balance with the constraints established by the strategy and EA teams.
Circle 3: Product Ownership and Detailed Design
At this point, I am sure that you can see where we are going here....just like themes and enterprise architecture constrain the decisions of the Product Owner team... user stories and software architecture constrain the decisions of the capability teams. We are taking the problem from a very high level of abstraction... through progressive elaboration... to the point we are ready to assign user stories to a capability team where user stories can be specified, designed, and coded at the detailed level.
This is where the rubber really meets the road. This is where the actual capabilities of the business are delivered. You have a team of engineers collaborating with a product owner on a day to day basis... making the daily trade-offs to deliver within the constraints established by the Product Owner team and the Software Architect. Again... each higher order team constrains the decisions of the lower order teams... not in a vacuum... but collaboratively with an established feedback mechanism.
Constraints and Feedback
Figure 2 shows the flow of constraints down the chain with feedback flowing back up the chain.
In this model... business decisions have to be made up front at a pretty high level of abstraction... that's reality and we have to deal with it. Enterprise teams do not get a free pass to deliver whatever they want... after all... most business do not have an emergent business model... they operate under a goal oriented model. Teams deliver on the goals and strategic objectives of the larger enterprise.
These business decisions though need to be made at the appropriate level of abstraction so that the teams can inspect and adapt their way to delivery. The business establishes the constraints but the team is free to be agile within those constraints... they can do what they need to do to deliver on the higher order objectives.
Okay... so what if the constraints are invalid or limit our options in an inappropriate way?
The idea is to mitigate the issue within the capability team... or if possible... at the current layer of abstraction. When the problem transcends the ability of that layer to resolve... it gets escalated up the abstraction hierarchy and mitigated at the next higher level. As deep or as wide as your agile enterprise is... constraints come down the hierarchy... and feedback goes up the hierarchy. Each level is responsible for managing trade offs until you reach a point where the issue has to be taken up to the next level.
