The book never talked about the business case of using this approach. For example, early implementation of functionality is early achievement of ROI. This needs to be shifted from a theoretical exercise to one that is compelling to the executive who will be paying for the project. I can see that one of their concerns will be loss of control.
There is a fairly sophisticated chartering activity I take projects through to get to the underlying assumptions and organizational goals. Once we lay those out so everyone understands them, the nucleus of the team creates a release plan with the business and develops the business case. This in turn is briefed to management for approval. Only with that approval does the project actually get initiated. The expectation I always set up for teams is that the critical 20% should be in the first release, because there will always be another project whose critical 20% has a higher priority that the second release of this project. Most projects will never have a second release and those few that do, will really be an entirely different project.
Once everyone understands this, we establish an iterative cadence to the development and go balls to the wall across the release pausing after each iteration only to 1) look back on how we did it and change the process if necessary and 2) ask the business if the assumptions made in the charter still hold and/or whether anything has changed at the business level such that we need to replan.
Tuesday 26 February 2008
Sunday 24 February 2008
Question #8
I can see the CFO of a company having heartburn with this approach since it implies a never ending project and budget requirements. (they pay our bill)
THIS IS THE KEY!!!! You found it after reading only 1 book too!
But really, this here becomes the rub. The neverending story. I fight this all the time. This is why I start with programmatic release planning with probabilistic dates for content specific releases. Once you start down that path and use both burnups and burndowns, it is much easier to contain and control a team and a release. Most CFOs are not willing to suspend disbelief and have heard so much bad stories that it is indeed a hard sell – this is why we need to talk to the CEO instead. Take a look at this: CEO to CIO and back. It is from my other blog and rather than repeat the thoughts here, go there and take a gander. It was a fairly cogent way of expressing the thoughts.
THIS IS THE KEY!!!! You found it after reading only 1 book too!
But really, this here becomes the rub. The neverending story. I fight this all the time. This is why I start with programmatic release planning with probabilistic dates for content specific releases. Once you start down that path and use both burnups and burndowns, it is much easier to contain and control a team and a release. Most CFOs are not willing to suspend disbelief and have heard so much bad stories that it is indeed a hard sell – this is why we need to talk to the CEO instead. Take a look at this: CEO to CIO and back. It is from my other blog and rather than repeat the thoughts here, go there and take a gander. It was a fairly cogent way of expressing the thoughts.
Friday 22 February 2008
Question #7
We need to have regular internal training for our SCRUM Masters so that we are always at least a little better than the clients we do business with.
Scrum masters do not get better with training – that is a misnomer that the world is still catching onto. Scrum masters get better with experience. When you stop having delivery responsibility it becomes really easy to excuse unsuccessful situations as the fault of other forces or individuals involved. However, in many cases, there will be times where the scrum master might choose a different path if they have responsibility for the delivery as well as the process. Those are the times and the areas that need to be investigated. Without the responsibility, you lose your edge (but inversely you increase your hourly rates – go figure!).
Our internal resources are always better than the client’s because we will have pulled them from the experienced part of the industry, rather than those folks who have merely taught the skills. I want people on my team who can say “something like this happened to me and this is what I did and why it worked or didn’t” I don’t want someone who will say “the book suggests that we do this, I can call author and ask for clarification if you want, but…” People whose only reference is the advice and direction of a book or teacher, no matter how good the book or the teacher, will be one dimensional. As my mom used to say, you catch more flies with honey than vinegar, but until you see a village consumed with e-coli, you don't really understand why you should catch those flies. Anti-patterns are hugely more valuable than patterns for teaching. I want my coaches to know the anti-patterns so that when the teams start falling into them it can be realized quickly and they can be hauled out before disaster strikes.
Scrum masters do not get better with training – that is a misnomer that the world is still catching onto. Scrum masters get better with experience. When you stop having delivery responsibility it becomes really easy to excuse unsuccessful situations as the fault of other forces or individuals involved. However, in many cases, there will be times where the scrum master might choose a different path if they have responsibility for the delivery as well as the process. Those are the times and the areas that need to be investigated. Without the responsibility, you lose your edge (but inversely you increase your hourly rates – go figure!).
Our internal resources are always better than the client’s because we will have pulled them from the experienced part of the industry, rather than those folks who have merely taught the skills. I want people on my team who can say “something like this happened to me and this is what I did and why it worked or didn’t” I don’t want someone who will say “the book suggests that we do this, I can call author and ask for clarification if you want, but…” People whose only reference is the advice and direction of a book or teacher, no matter how good the book or the teacher, will be one dimensional. As my mom used to say, you catch more flies with honey than vinegar, but until you see a village consumed with e-coli, you don't really understand why you should catch those flies. Anti-patterns are hugely more valuable than patterns for teaching. I want my coaches to know the anti-patterns so that when the teams start falling into them it can be realized quickly and they can be hauled out before disaster strikes.
Question #6
The book seems to make the assumption that everything is development work and only the minimal documentation required to develop should be built. I would argue that this approach will be disastrous for maintenance. I’ve seen groups have to totally rewrite a new system because it wasn’t maintainable. Some documentation isn’t for the team. It is for the next team.
You are right. As I said, the problem with many organizations' attempts at Agile is that they religiously follow the books. In turn, the books simplify the approach so that it is easily understandable and easily implementable, though if you want to scale it, you must understand how Agile works at a deeper level (understand agile). Then, you must be able to abstract it up a level or two and if you don’t have an experienced coach, you must be willing to accept some trial and error in your path to effectiveness.
This being said, agile is all about doing the least amount of work necessary to achieve the acceptance criteria. If documentation needs to be done, regardless as to whether it is end-user, regulatory, or interim step documentation, it needs to be incorporated into the stories as acceptance criteria and no story will then be considered done if its requisite documentation is not complete.
You are right. As I said, the problem with many organizations' attempts at Agile is that they religiously follow the books. In turn, the books simplify the approach so that it is easily understandable and easily implementable, though if you want to scale it, you must understand how Agile works at a deeper level (understand agile). Then, you must be able to abstract it up a level or two and if you don’t have an experienced coach, you must be willing to accept some trial and error in your path to effectiveness.
This being said, agile is all about doing the least amount of work necessary to achieve the acceptance criteria. If documentation needs to be done, regardless as to whether it is end-user, regulatory, or interim step documentation, it needs to be incorporated into the stories as acceptance criteria and no story will then be considered done if its requisite documentation is not complete.
Thursday 21 February 2008
Question #5
SCRUM talks about “sprints”. How about carrying the analogy forward and awarding ribbons at the end of each sprint. Blue if the target was achieved, Red if the target met 95% of expectations, etc. The point is that the set of ribbons that a team receives overtime become their scorecard of achievement. It is management’s job to ensure that they are successful (remove barriers, provide training, etc.) It also makes the team accountable to achieve results.
Agile tends to look at the completion of stories (or usecases or features or units of work) as a binary event. When the story is written, an acceptance criteria is defined that meets both the Verification requirements and the Validation requirements. This being said, during a sprint - or as it is more generally called, an iteration – things can be marked as done only if both QA and the Business agree that Verification and Validation have been satisfied.
At the beginning of the iteration, the team committed to completing a certain number of items. The burndown charts how they are doing and allows both the project team and outside observers to wonder out loud whether they are going to be able to meet their commitment or not and if not, what they can do to help facilitate meeting it. It begins giving you leading indication immediately and sponsors such conversations much earlier than with other methodologies.
Additionally, there is another graph called a burnup that tracks the teams progress against its release target. The two charts have to be used in concert to truly help control the project, as the team uses only the burndown, they can continually adjust the level of their commitment to the point where they are not really taking on much if any new work; however they are indeed meeting it each iteration and winning kudos from their management. In this situation, the Projected Release dates looms large only to find that most of the work is not done. By trending the number of stories “completed” after each iteration against the goal set during the project’s chartering process, the organization gets a much better picture of the actual productivity of the team.
There is another derived metric that has much controversy about it in the agile community and it is Velocity. I use velocity as the effectiveness of the team on the project. This is a fine distinction and needs to be made. People do a lot of stuff at work, most of which is important to the business at some level, even if it is otherwise classified as overhead. We encourage teams to not multi-task so that we can eliminate costly context switching times, but sometime it has to happen. Therefore, when we look at velocity, we are looking at the effectiveness of the team on this project. Low velocities are always cause for investigation and discussion, but it MUST be remembered that low velocity is often not the fault of the individuals, but rather the environment they have been cast into to execute the project.
Now, if you have the team estimate their work in a unit called Ideal Hours, then you can create a ratio between Ideal Hours and Actual Hours (duration), which gives you a measure of the effectiveness of the team. Ideal Hours are uninterrupted hours an individual or team can work on a task. Uninterrupted means no phone calls, no IMs, no email, no meetings, nothing that is not directly associated to the task at hand. When we train this, we talk about coming into work on the Saturday they were doing the upgrade to the Exchange Server and the PBX at the same time, so you got to sit in front of your workstation completely uninterrupted and hyper-focus, getting done far faster than you imagined possible….. This is the same concept that TOC/CCPM refers to a aggressive but possible estimates, or estimating at the 50th percentile for probability of completion. There is indeed an entire art to estimating, and the agile approach incorporates many approaches that actually produce a far better over estimate than any other methodology – we can talk about those separately.
Once you have the estimates in the Ideal Hours, the ratio is developed against durational hours of the team (these are all team measures) where you compile the total number of hours available to the team minus their preplanned vacation, training, or other non-work commitments. The Velocity measure is usually, for a highly functioning team, between 25% and 45% depending upon its size and whether or not it is distributed (collocation increases velocity). Velocity is also a function of the complexity of the project and the degree innovation plays in the ultimate results, so you would expect a highly distributed project with a high degree of technical difficulty and a fair amount of innovation to have a much lower velocity than a legacy conversion. The skilled coach or management team will understand these factors from the project’s charter and will acknowledge it, but the real value is as a base line factor. If the team varies substantially from expected velocity values, the work is potentially more complex than they thought or they are deviating from the desired expectations from the business, or everything is fine and great things are happening – regardless, a question should be surfaced and answered.
So, back to your point. All of that is correct. You do need to know what you are actually measuring though, before you start rewarding. But the ribbon idea is great - a blue ribbon sprint as versus a red ribbon sprint!
Agile tends to look at the completion of stories (or usecases or features or units of work) as a binary event. When the story is written, an acceptance criteria is defined that meets both the Verification requirements and the Validation requirements. This being said, during a sprint - or as it is more generally called, an iteration – things can be marked as done only if both QA and the Business agree that Verification and Validation have been satisfied.
At the beginning of the iteration, the team committed to completing a certain number of items. The burndown charts how they are doing and allows both the project team and outside observers to wonder out loud whether they are going to be able to meet their commitment or not and if not, what they can do to help facilitate meeting it. It begins giving you leading indication immediately and sponsors such conversations much earlier than with other methodologies.
Additionally, there is another graph called a burnup that tracks the teams progress against its release target. The two charts have to be used in concert to truly help control the project, as the team uses only the burndown, they can continually adjust the level of their commitment to the point where they are not really taking on much if any new work; however they are indeed meeting it each iteration and winning kudos from their management. In this situation, the Projected Release dates looms large only to find that most of the work is not done. By trending the number of stories “completed” after each iteration against the goal set during the project’s chartering process, the organization gets a much better picture of the actual productivity of the team.
There is another derived metric that has much controversy about it in the agile community and it is Velocity. I use velocity as the effectiveness of the team on the project. This is a fine distinction and needs to be made. People do a lot of stuff at work, most of which is important to the business at some level, even if it is otherwise classified as overhead. We encourage teams to not multi-task so that we can eliminate costly context switching times, but sometime it has to happen. Therefore, when we look at velocity, we are looking at the effectiveness of the team on this project. Low velocities are always cause for investigation and discussion, but it MUST be remembered that low velocity is often not the fault of the individuals, but rather the environment they have been cast into to execute the project.
Now, if you have the team estimate their work in a unit called Ideal Hours, then you can create a ratio between Ideal Hours and Actual Hours (duration), which gives you a measure of the effectiveness of the team. Ideal Hours are uninterrupted hours an individual or team can work on a task. Uninterrupted means no phone calls, no IMs, no email, no meetings, nothing that is not directly associated to the task at hand. When we train this, we talk about coming into work on the Saturday they were doing the upgrade to the Exchange Server and the PBX at the same time, so you got to sit in front of your workstation completely uninterrupted and hyper-focus, getting done far faster than you imagined possible….. This is the same concept that TOC/CCPM refers to a aggressive but possible estimates, or estimating at the 50th percentile for probability of completion. There is indeed an entire art to estimating, and the agile approach incorporates many approaches that actually produce a far better over estimate than any other methodology – we can talk about those separately.
Once you have the estimates in the Ideal Hours, the ratio is developed against durational hours of the team (these are all team measures) where you compile the total number of hours available to the team minus their preplanned vacation, training, or other non-work commitments. The Velocity measure is usually, for a highly functioning team, between 25% and 45% depending upon its size and whether or not it is distributed (collocation increases velocity). Velocity is also a function of the complexity of the project and the degree innovation plays in the ultimate results, so you would expect a highly distributed project with a high degree of technical difficulty and a fair amount of innovation to have a much lower velocity than a legacy conversion. The skilled coach or management team will understand these factors from the project’s charter and will acknowledge it, but the real value is as a base line factor. If the team varies substantially from expected velocity values, the work is potentially more complex than they thought or they are deviating from the desired expectations from the business, or everything is fine and great things are happening – regardless, a question should be surfaced and answered.
So, back to your point. All of that is correct. You do need to know what you are actually measuring though, before you start rewarding. But the ribbon idea is great - a blue ribbon sprint as versus a red ribbon sprint!
Wednesday 20 February 2008
Question #4
One of the ways to help management feel like they are in control is through metrics. Schwaber's book suggests 4 charts or graphs to manage agile. We probably need more, and more focused on achieving business value. I think I should merge the “Implementing Goal Driven Metrics” class that I teach from the SEI into our implementation of the methodology.
I agree on the merger. I am not 100% convinced we need more than a small number of metrics to adequately control projects nor to drive transformation. Take a look at the my paper on Metrics for an Agile PMO. The Burndown chart is extremely powerful, as it tracks estimate to complete, and probability to complete as well as commitment and plan. It can also be broken down to display development, validation, and verification as three separate measures.
This is one area where the concept behind the balanced scorecard got it right. I believe that agile's Transparency practice helps us figure out how actions inter-relate and roll up through the various decision making levels within an organization (typically, ultimately to the Finance with profitability). I think as part of the methodology, we should recommended a balanced scorecard type metric program to align the entire organization (not just development or engineering) and allows them to put in some collected metrics at the bottom and demonstrate how they roll up to the Red/Yellow/Green/Blue indicators at each successively higher level. This would help folks implement methodology based on value proposition and indeed demonstrate that value prop explicitly.
I agree on the merger. I am not 100% convinced we need more than a small number of metrics to adequately control projects nor to drive transformation. Take a look at the my paper on Metrics for an Agile PMO. The Burndown chart is extremely powerful, as it tracks estimate to complete, and probability to complete as well as commitment and plan. It can also be broken down to display development, validation, and verification as three separate measures.
This is one area where the concept behind the balanced scorecard got it right. I believe that agile's Transparency practice helps us figure out how actions inter-relate and roll up through the various decision making levels within an organization (typically, ultimately to the Finance with profitability). I think as part of the methodology, we should recommended a balanced scorecard type metric program to align the entire organization (not just development or engineering) and allows them to put in some collected metrics at the bottom and demonstrate how they roll up to the Red/Yellow/Green/Blue indicators at each successively higher level. This would help folks implement methodology based on value proposition and indeed demonstrate that value prop explicitly.
Question #3
There needs to be a balance between control (old style management) and empowerment (agile). The balance may be a minimalist approach to the CMMI. Only put what is necessary to achieve the CMMI in a manner that enables empowerment. I think (especially for an organization getting started in this approach – or with a older workforce) that management needs to feel like they are in control (their performance payment (bonus) is probably dependent upon this). The CMMI can give them some level of control.
One of the first steps I take during a transformation is to understand what the compensation practices are at various levels of the organization. Bonuses and other compensation mechanisms are how professionals are ‘graded’. The age old saying “Tell me how you will measure me and I will tell you how I’ll behave”, is highly accurate. If your organization aligns its compensation plan so that its people are incentivized to try and maintain a transformation (or at least the transformative practices), then the probability of success goes up dramatically. If their compensation plan is orthogonal to the transformation, you can kiss the transformation goodbye.
There is a strong attribute of agile that stands out here, and that is the practice of transparency. By both teaching and encouraging teams to be transparent with their projects and programs, then they can keep their empowerment but the control issue tends to dissipate. By ensuring that organizations out side the project team have access to up to date status and information, then they can maintain the level of oversight that they feel is warranted with out having to resort to a fully command and control mode of operation.
One of the first steps I take during a transformation is to understand what the compensation practices are at various levels of the organization. Bonuses and other compensation mechanisms are how professionals are ‘graded’. The age old saying “Tell me how you will measure me and I will tell you how I’ll behave”, is highly accurate. If your organization aligns its compensation plan so that its people are incentivized to try and maintain a transformation (or at least the transformative practices), then the probability of success goes up dramatically. If their compensation plan is orthogonal to the transformation, you can kiss the transformation goodbye.
There is a strong attribute of agile that stands out here, and that is the practice of transparency. By both teaching and encouraging teams to be transparent with their projects and programs, then they can keep their empowerment but the control issue tends to dissipate. By ensuring that organizations out side the project team have access to up to date status and information, then they can maintain the level of oversight that they feel is warranted with out having to resort to a fully command and control mode of operation.
Tuesday 19 February 2008
Question #2
2. For some companies, there will be resistance to SCRUM. How close is it to lean project management?
Lean Project Management is a separate approach. Clearly Lean and Scrum are related, Lean has been adapted fairly successfully to SW by Mary Poppendieck (see attached), and though there is a fairly active consulting practice based around it, the methodology has not taken off as Scrum or Agile has, due to the fact that it is more complex to implement and requires more rigor and insight to initiate in any organization. The seven principles of Lean can be simply associated to both System Development (no surprise) and software development (with more abstraction). They are:
As an aside, Capital One initiated their transformation with a desire to reduce time to market of their projects and started with Lean as a methodological framework within which they used Agile and Scrum practices as the implemented procedures
Lean Project Management is a separate approach. Clearly Lean and Scrum are related, Lean has been adapted fairly successfully to SW by Mary Poppendieck (see attached), and though there is a fairly active consulting practice based around it, the methodology has not taken off as Scrum or Agile has, due to the fact that it is more complex to implement and requires more rigor and insight to initiate in any organization. The seven principles of Lean can be simply associated to both System Development (no surprise) and software development (with more abstraction). They are:
- Eliminate Waste
- Amplify Learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- See the whole
As an aside, Capital One initiated their transformation with a desire to reduce time to market of their projects and started with Lean as a methodological framework within which they used Agile and Scrum practices as the implemented procedures
Monday 18 February 2008
10 Questions generated from Schwaber's Agile Project Management with Scrum
These questions or points were raised by a friend of mine who is an agile novice but has a lifetime of Process Improvement experience and is one of the few CMMI HM Assessors in the country. I find them quite interesting. The responses are mine.
Question 1: Agile makes a lot of assumptions about worker’s behavior. This may be true for some organizations. When it is an older or culturally ingrained organization or has lots of older workers, the SCRUM approach will probably be a challenge to implement.
Many culturally ingrained organizations immediately realize that this methodology is not for them and never attempt the transformation. A subset of them, typically the most interesting subset – such as the Travelers, Sabre, The Gap – realize that they are becoming irrelevant in their industry and must change something. The decision is usually made on the Business side or in Sr. Mgmt. Some how, someone latches onto Agile and decides it is the right path. Rarely does anyone consider whether or not it is a cultural fit for their groups.
In situations like this, corporations that attempt to do a transformation on their own usually find so much active and passive resistance that they are not experienced in over coming that they fail quickly. In organizations that bring in consultants to help with the transformation, I have still seen a fairly low rate of success. I attribute this to the fact that though the consultants can address and over come the active resistance, they are expensive and the passive resistance can and does outlast them. Once the consultants are gone, there is a pretty high probability that the culturally ingrained approach will resurface and the transformation will wither, sometimes leaving the company unable to develop at all.
Question 1: Agile makes a lot of assumptions about worker’s behavior. This may be true for some organizations. When it is an older or culturally ingrained organization or has lots of older workers, the SCRUM approach will probably be a challenge to implement.
Many culturally ingrained organizations immediately realize that this methodology is not for them and never attempt the transformation. A subset of them, typically the most interesting subset – such as the Travelers, Sabre, The Gap – realize that they are becoming irrelevant in their industry and must change something. The decision is usually made on the Business side or in Sr. Mgmt. Some how, someone latches onto Agile and decides it is the right path. Rarely does anyone consider whether or not it is a cultural fit for their groups.
In situations like this, corporations that attempt to do a transformation on their own usually find so much active and passive resistance that they are not experienced in over coming that they fail quickly. In organizations that bring in consultants to help with the transformation, I have still seen a fairly low rate of success. I attribute this to the fact that though the consultants can address and over come the active resistance, they are expensive and the passive resistance can and does outlast them. Once the consultants are gone, there is a pretty high probability that the culturally ingrained approach will resurface and the transformation will wither, sometimes leaving the company unable to develop at all.
Thursday 14 February 2008
Thursday 7 February 2008
Transparency
One of the things that Margaret Wheatley says in her book “Leadership and the New Science” strikes to the heart of why we preach transparency. The statement:
Often, the PMs are not overtly hiding anything, they just don’t have the data to really know their own status. Stepping up to an individual and asking them what percent of their task is complete is at best and estimate of an estimate (how much have I really accomplished of what I thought I needed to do). The lack of precision is enough to give the PM a sufficient level of discomfort to the certainty and so causes them to rightly be unable to confidently report progress – in other words, since they don’t have the information in the form they need, they make it up. The quest then, is to find a way such that progress is essentially black and white – to eliminate the ambiguity and ensure that the PMs have the information they need to do their work.
By forcing the programs and projects to be fully transparent and show progress in tangible terms (hey, how about that burndown or burnup chart?), the PMO spends less time wading cautiously through the weeds and more time actually helping. If all the signs are positive, the review can be over in moments. If the signs are not, the program manager becomes responsible for explaining what the data implies and what they have done about the anomalies. Then, when necessary, the help can begin the PMs stop sleeping with the fishes.
† Thanks to Tom Looy (http://conversationswithandrew.blogspot.com/) for this.
Everybody needs information to do their work. We are so needy of this resource that if we can’t get the real thing, we make it up.†On projects, we always used to say – no surprises good or bad. It was a mantra that we used at the PMO level to help project managers feel comfortable coming to us for both reporting and for requesting. The general idea was that if you surfaced a risk, someone who’d been there before could help you work it before it became an issue. Mostly people saw surfacing as an admission of incompetence – and no one liked that – so you can imagine how often we got to help. The unfortunate side effect of this was you never saw real risks, just real problems. At each review, the project managers had plenty of risks and an occasional issue to expose to the group, but on closer inspection, these always turn out to be either trivial issues or fabricated risks. The real ones stayed swimming voraciously like trolling barracuda in the murky shallows by the program’s banks.
Often, the PMs are not overtly hiding anything, they just don’t have the data to really know their own status. Stepping up to an individual and asking them what percent of their task is complete is at best and estimate of an estimate (how much have I really accomplished of what I thought I needed to do). The lack of precision is enough to give the PM a sufficient level of discomfort to the certainty and so causes them to rightly be unable to confidently report progress – in other words, since they don’t have the information in the form they need, they make it up. The quest then, is to find a way such that progress is essentially black and white – to eliminate the ambiguity and ensure that the PMs have the information they need to do their work.
By forcing the programs and projects to be fully transparent and show progress in tangible terms (hey, how about that burndown or burnup chart?), the PMO spends less time wading cautiously through the weeds and more time actually helping. If all the signs are positive, the review can be over in moments. If the signs are not, the program manager becomes responsible for explaining what the data implies and what they have done about the anomalies. Then, when necessary, the help can begin the PMs stop sleeping with the fishes.
† Thanks to Tom Looy (http://conversationswithandrew.blogspot.com/) for this.
Wednesday 6 February 2008
A voice for discontinuity!
There has been a growing discussion of late for what is being called the “continuous scrum” or the Kanban approach. Some have even talked about how if 4 week sprints are good, and 2 better, then maybe we keep driving down to the limit and use 0 week iterations – essentially, establish a continuous model. The concept behind this is thrilling and the results I have seen suggest teams can notch up their productivity and increase their throughput as well. For a high-performance team, this is like a nitro boost into their engine. They become the reality every truly agile product manager dreams of!
Unfortunately, not every team is a high performance team and not every product manager is truly agile. The risk that needs to be assessed is what happens to teams that don’t quite reach the plateau of High-Performance or are asked to operate in an environment that is anything less than fully agile enabled?
First, a high performance team is a self-optimizing team. In terms of the agile maturity model, it would be a level 5 maturity team – one that can evaluate and self-correct. When moving to a continuous cycle (Zero length Iterations), there is a substantive risk that a team without the ability to self-optimize could, put the project into a PIO -like negative feedback cycle that would cause irreparable damage to the goals and objectives of the effort. Clearly, seasoned pilots and highly experienced coaches are able to put the ship right with an aggressive but calm damping approach, but we often do not have these types of people available.
In a continuous cycle, there are no “fire-stops”. Once a negative feedback cycle becomes instantiated, the team must first recognize the signs and then be able to fight the degeneration themselves; hopefully in time to save the project. In an iterative process, every iteration review produces a fire stop – an opportunity for the team to check point with their customer and their organization. One activity I encourage teams I coach to go through during each of these iteration reviews is to bring out the assumptions documented during the project chartering activity and to ask the Product Owner whether or not any of the assumptions have changed, as it can substantially change priorities and goals if they have.
Bottom line is I do not advocate stepping into a continuous cycle until everyone is convinced that the maturity level of the team is such that this risk is mitigable. Even in those situations, I strongly believe that there should be an operative and equally mature Agile PMO in place in the organization, to act as a check and balance for the corporation. Once a team reaches the level where a continuous cycle is achievable, it would be extremely easy for them to get in a hyper-productive groove and loose sight of corporate goals and objectives which may change outside of the peripheral vision of the team.
Unfortunately, not every team is a high performance team and not every product manager is truly agile. The risk that needs to be assessed is what happens to teams that don’t quite reach the plateau of High-Performance or are asked to operate in an environment that is anything less than fully agile enabled?
First, a high performance team is a self-optimizing team. In terms of the agile maturity model, it would be a level 5 maturity team – one that can evaluate and self-correct. When moving to a continuous cycle (Zero length Iterations), there is a substantive risk that a team without the ability to self-optimize could, put the project into a PIO -like negative feedback cycle that would cause irreparable damage to the goals and objectives of the effort. Clearly, seasoned pilots and highly experienced coaches are able to put the ship right with an aggressive but calm damping approach, but we often do not have these types of people available.
In a continuous cycle, there are no “fire-stops”. Once a negative feedback cycle becomes instantiated, the team must first recognize the signs and then be able to fight the degeneration themselves; hopefully in time to save the project. In an iterative process, every iteration review produces a fire stop – an opportunity for the team to check point with their customer and their organization. One activity I encourage teams I coach to go through during each of these iteration reviews is to bring out the assumptions documented during the project chartering activity and to ask the Product Owner whether or not any of the assumptions have changed, as it can substantially change priorities and goals if they have.
Bottom line is I do not advocate stepping into a continuous cycle until everyone is convinced that the maturity level of the team is such that this risk is mitigable. Even in those situations, I strongly believe that there should be an operative and equally mature Agile PMO in place in the organization, to act as a check and balance for the corporation. Once a team reaches the level where a continuous cycle is achievable, it would be extremely easy for them to get in a hyper-productive groove and loose sight of corporate goals and objectives which may change outside of the peripheral vision of the team.
Subscribe to:
Posts (Atom)