• Support
  • Newsletter
  • Agile 101
  • Contact Us
  • Scrum - Keeping It Simple

    Wednesday, February 24, 2010 by V. Lee Henson CST

    In the world of IT, as systems become more powerful and complex, managing these complex systems becomes easier and easier. A big part of what I have dubbed the IT revolution comes from a new group of revolutionaries pushing forward the message that serious does not need to be complex. In the world of agile development, we have been advised that agile does not mean fragile. Today I am going to zoom in to a little old thing called Scrum.

    When Scrum was invented and first implemented, it was meant to be a simple framework with few roles, meetings, and artifacts. I now feel no choice but to ask, what in the world happened to the simplicity? As it has evolved, Scrum and agile project management in general have become polluted. I have even heard many agile scrum coaches proclaim that a ‘vanilla Scrum’ implementation will only work in small organizations with simple projects. Although this could be no further from the truth, I still feel the pain from teams who are suffering from being bitten on their Scrum-butts!

    All too often, at the direction of someone in an agile management position, we abandon the simple things we know to be true. Whether it is done in an effort to find the holy grail of increased efficiency, or to make the adoption an easier to swallow pill, does that make it all right? Does simple with few rules, roles, and artifacts necessarily mean easy? Where do we draw the line? 

    In this article, I intend to present why teams choose to struggle with something so simple. Let’s start by taking a walk down Scrum Lane and discussing some of the pieces that people struggle with most.

    Roles
    The first of three concepts we will discuss today is roles. I cannot help but notice that one of the largest questions organizations face as they transition to agile is "where does my role fit into the mix?" People are constantly trying to squeeze what they do into the agile mold, when in fact there are truly only three positions, regardless of agile methodology: Customer, Implementor, and Facilitator. In Scrum, the three roles are Product Owner, Scrum Master, and Team Member. Each role has been called a number of different names, but the simple truth is no matter what HR calls you or what is on your business card, you should fall into one of these three roles. If you do not, it may be time for you to do a serious introspective and identify how you can modify your role to fit better into one of the three identified.

    Meetings
    The second concept up for discussion is the correct Scrum meetings. Scrum was founded on the premise of three meetings. The first is the Daily Standup (or Daily Scrum). The daily meeting is a chance for the team to report their progress to each other! This is the perfect time for the team to use subtle pressure to ensure accountability for each individual. The meeting has only three questions for each individual to answer:

    1)      What have you done since we last met?
    2)      What are you planning to do until we meet again?
    3)      Is there anything preventing you from completing the items you committed to? 

    The meeting is capped at fifteen minutes in length. No problem-solving happens here. The team simply identifies issues and takes them offline to resolve. Attaining the right level of detail is the key to making this meeting successful. This meeting should happen in the same location at the same time, every day without exception.

    The second meeting is Sprint Planning. The most common misconception is that no initial preparation takes place prior to this meeting, which is simply not true. Key considerations must be met to achieve success. The product backlog must be properly groomed and backlog items must be ready to be placed into a Sprint. An architectural runway must also be in place for the team to be able to successfully plan for the work. Many people forget these critical steps, and when this falls squarely on the team, the team fails. Effective Sprint planning largely contributes to a team’s success in adopting or implementing Scrum.

    The team should meet at the beginning of the Sprint to review the work for the upcoming sprint and break the work down into small tasks and tests. This is a learned art and you should never expect a team to catch everything on the first pass. This meeting should be brief and time-boxed equivalent to one hour per week of your team’s sprint length. Four week sprint = four hour meeting. Proper execution in the Sprint Planning meeting is critical to the team’s success.

    The third Scrum meeting is Sprint Review, which includes the demo and retrospective. Of all the Scrum meetings, this one can prove to be the most beneficial to the success of the team. The entire concept of inspection and adaptation rides on the premise that the key stakeholders will have a chance to review what the team has created and to provide instrumental feedback. This feedback is what helps the team stay focused on exceeding the stakeholder’s expectations and allows all key parties to be on the same page. The retrospective is the only opportunity that the team has to inspect and adapt the process. Although at times the meeting may turn toward evaluation of individuals on the team, it is critical to maintain focus on the process and look for ways to prepare an agenda that allows the team to stay focused on delivering meaningful results in the retrospective. The team will be grateful that you helped them stay on track.

    Artifacts
    The third and final concept to keep Scrum simple is focusing only on the three artifacts. The three Scrum artifacts are as follows:

    1) Product Backlog – This should be a well-managed list of work to do in upcoming sprints. The work should be broken down in a manner that makes it easily consumable within a single sprint.
    2) Sprint Backlog – This backlog should contain all of the small tasks & tests needed to complete a subset of work from the product backlog. This is the actual work that the team commits to deliver.
    3) Burndown Chart – This visual indicator is a constant reminder of the work remaining to be completed as part of the sprint commitment.

    I think too often we try to take this very basic framework and overcomplicate it to fit our organizational culture. If we get back to basics, and focus on keeping it simple, we will all re-discover that Scrum is a true flavor of agile project management and it really does work!

    Agile Adoption For Managers

    Saturday, January 16, 2010 by V. Lee Henson CST

    One question that I run across quite often is "What will agile development do for my organization?" What many people mistakenly do is equate agile project management with doing more work, with less documentation and fewer people. Although the premise is to get more done in a more favorable way, I have never met a team that could successfully implement agile principles without having to slow down first.

    In fact, I would challenge that initially agile development causes teams to move slower! I know what your next question is: "Why bother?" Well, please allow me to clarify. Agile project management is your friend! Many managers do not take the time to understand what agile of any flavor will do and are completely caught off guard when they discover that things do not always fall out exactly like they had envisioned. 

    After enduring endless nagging by my peers, I decided that a guide was needed for managers to set true expectations with regard to an agile development project roll out. When I consulted with some of the organizations I have worked pretty extensively with, they all replied that they would be delighted to give me input, but were disappointed that it would take me this long to put a simple list like this together. For all of you who wish you had this already, I am sorry in advance. Now is the time to get busy and take action! 

    This two-part series will engage agile managers at any level and help them best understand the fundamentals and embrace what they need to know about agile. The long-preserved secret is that agile project managers really only need to know three things to be successful.

    1. Become a servant leader. Although it may take some time to redirect your energy toward removing obstacles, the new focus will allow you to concentrate more on the larger picture and less on the day-to-day needs of the team that works for you. Less command & control and more accountability will make you a sure winner.
       
    2. Allow agile to identify areas where improvement is needed. I recently engaged an organization and met a non-believer. When I asked him about his experience with agile, I nearly had a heart attack when he claimed that it simply does not work. "All agile did was identify all of the things we were doing wrong," he said. I just smiled and nodded. Those are the things that you were meant to be doing better. Take advantage of this golden opportunity and allow agile to help you get better!
       
    3. Take the time to understand the fundamentals of the framework, methodology, and terminology! How much more will the team respect you for taking the time to invest in their success by learning more about what you are asking them to do? We all know that things will need to storm a little before becoming a high performing team.

    The first step will be the easiest one. It is all a matter of breaking down where and how accountability may rest. Most managers fail to realize that there are qualified people who work for them that can take on most of what you throw at them. I often find myself in management sessions telling them to try and delegate their way out of a job. I assure them that by doing so, they will find new ways to engage and work with the organization and find new ways to help them be successful.

    It is essential to recognize that a large number of the problems teams face can and should be handled by the team themselves. If the team ever encounters a problem that is out of their league, they will always have someone to turn to in the form of a project manager, ScrumMaster, or product owner who can assist them in resolving most common issues. This is the second line of defense.

    In rare cases where this second group cannot bring resolution to an issue, the issue is sometimes brought to the attention of management. I guess this begs the question, "How do I keep busy now?" Well, for starters, this allows you to better focus on delivery and execution of the vision. Many agile organizations get lost in the vision and lose focus on the strategy needed to execute the vision. If the team has a clear path and direction from you, they will be successful.

    Once you realize that you can relax, the final step is to help the team understand commitment and responsibility. When I am working in the role of management, many people comment that I allow my teams an excessive amount of responsibility. I let the teams self-regulate for the most part, and hold each other to the highest standards. As a result, I am able to set my expectations very high. There is no confusion surrounding my expectations: I fully expect that you will do all that you have promised. This type of relationship is healthy and the teams enjoy both the freedom and the level of accountability I hold them to.

    The next step is to allow agile to identify key areas for improvement. Do not fear what the agile process identifies! In fact, I hope that you will embrace and address all that comes to the surface.

    One of the keys to agile success is transparency. The right hand needs to know and understand what the left hand is trying to do. The teams will have the greatest chance of success when common obstacles can be identified and removed. Teams discover that the business transforms into a place where they actually enjoy coming in to work. Without transparency, this could not be possible.

    Embracing transparency and what it exposes is not intended to be an easy undertaking. Expect the storm and celebrate the success once the storm dies down and the team embraces accountability. Managers become part of a brain trust that will rely on results of the delivery team in order to make sound financial and business decisions. The key here is to teach the teams that with great power comes great responsibility. They will continue to be cast in a positive light for as long as they continue to deliver.

    Finally, in order to be successful, you need to show the team that you have a vested interest in their success. This is your chance to do the research needed and show the team that you do understand what they are doing and support their effort. In early 2010 I hope to publish a glossary for managers that will assist them in finding the information they need to help their teams taste success.

    Until then, I have left you with enough to work on. Enjoy the post and I will continue soon.

    Building Agility for the New Year!

    Friday, January 15, 2010 by V. Lee Henson CST
    At this time of year, each of us have made New Year's Resolutions. Some of us want to lose weight, or eat less sweets. Some want to exercise more often, or just get in better shape. In the agile development community, I am asking you to consider a different type of resolution. It is all well and good for us to do any of the items listed above. They will each help us to become a better person. The question I have is, "What can you do to better implement agile processes within your organization?"

    Over the next few weeks, I hope to address topics regarding agile adoption and what it should mean to you and your organization. Call me a personal trainer if you will, but I remember the difference between when I attempted to lose a few pounds on my own, and when I had the help of a personal trainer to assist me. With a lot of focus and a little boost from someone on the outside, I got to see amazing things happen.

    I am hoping you will take advantage of my writing as we take an opportunity to study each role in the agile process in review, and attempt to identify ways that we can have a better or renewed impact on our projects. Let's take the time to inspect and adapt ourselves and make the new year one to remember. Although for many of you this may feel like a quick refresher course, I hope that you will patiently follow along and just try to identify one way in which you could ratchet it up a notch.

    We will begin the series by addressing the needs of the business and focusing on why managers adopt agile frameworks for their organizations. Let's get started and I look forward to working out with you and performing our Agile Tone Up! May this New Year and decade bring you much health, wealth, and success!

    Do you See What I see?

    Monday, December 21, 2009 by V. Lee Henson CST

    Agile project management has finally started to grow up and mature. On the heels of multiple training and coaching engagements, one thing I have learned is that agile has certainly made its way into enterprise level application development. Software development tools have evolved, and people have changed the end delivery method for getting things done. One constant that has held true throughout the test of time is the capability to work in an environment where everything is visible.

    Many agile organizations struggle with the prospect that visibility and transparency may not help everyone see eye to eye. The fact is, even though agile, Scrum, XP and the like have all taken monumental steps toward enterprise level adoption, the key to organizational success remains establishing and maintaining a solid foundation. One core success factor remains the ability to retain transparency and keep focus on the ability to inspect and adapt. This is not intended to be confused with scope creep or gold plating.

    In fact, one of the biggest hurdles I run into when agile starts to grow is the inability of the organization to learn from and accept the nature of what change has presented. Although from a business perspective we may all still see things a little bit differently, we need to learn how to keep our focus and learn from the error in our path. We need to take on the pressure of increased visibility and treat it as an opportunity for growth.

    Whether our team is just passing through storming and beginning to norm, or just beginning to form and has not reached this monumental step, we need to teach people that it is better to see eye to eye, and that even though the road may not always be a primrose path, the path we take will continue to teach us to be the best we can be with regard to agile project management. Enterprise level agile adoption is not always an easy sell, but neither is any process that may require us to refocus and slow down a bit.

    Let us each take a step back and a deep breath. Even though we may not be resolute in our belief that complete transparency will lead to enhanced process scenarios, we will quickly grow to understand that success relies on our ability to accept these core fundamentals.

    T'was Agile - A Holiday Treat

    Friday, December 18, 2009 by V. Lee Henson CST
    Twas the night before code drop and all through the land
    Not a person was coding, not even one hand

    The code was all tested and checked in with care
    Even the documentation was completed and there

    The PMO Director & VP of Dev were nestled all warm and snug in their beds
    While visions of bonuses danced in their heads

    Joe closed his laptop and Sue hit the sack
    Knowing morning was near and they needed the nap

    When from my pocket there arose such a clatter
    I reached for my iPhone to see what was the matter

    To the office I flew like a Senior VP
    Tore open my briefcase and fired up the PC

    When what in my unsettled eyes might appear
    But an incomplete test case as I trembled in fear

    I regained my senses and checked out the code
    Reviewed the regression and distributed the load

    It passed all the tests now, my mind was at ease
    Knowing that many would certainly be pleased

    That I put forth such effort on a cold chilly night
    To re-sync our code and ensure all was right

    Soon morning approached and I knew not to worry
    As none of the testing was crammed in a hurry

    It makes my heart filled with holiday cheer
    To know Agile methods make everything clear

    As the holidays are with us and our hearts fill with joy
    Help us all to remember the framework we enjoy

    On XP, on Scrum, On Kanban & Lean,
    On DSDM, On AgileUP, On Crystal Extreme

    To the ends of the project, no greater joy shall we call
    Than celebrate, celebrate, celebrate all

    As we conclude the current project and realign our sites
    Happy Holidays to all and succeed with Agile Might!

    Agile Credit Scores - A story of Technical Debt for Managers

    Monday, December 14, 2009 by V. Lee Henson CST
    So, I know what you are thinking.. Has he lost his marbles? What on Earth does a good credit score have to do with all things Agile project management related? Actually, I would argue the two are more tethered than one might imagine. In fact, the two are nearly synonyms. Allow me to explain.

    From a very early age we are taught to save for what we want and spend only for what we really need, yet more and more young people are being introduced to the concept of credit cards. Colleges are allowing creditors to offer students exclusive accounts without educating them about the risks. Often they don't see the warning signs, and don't understand the longterm ramifications until they are in over their heads.

    Every agile team has been issued in essence a platinum credit card. A card with no limit that they have been instructed to use wisely. Even with this as a consideration, cardholders still spend far in excess of what would be considered a reasonable amount. This is done under the premise that as long as they meet the minimum required monthly payments, that the debt will eventually go away.

    Realistically, however, when making only the minimum monthly payment, the debt almost never goes away and in some cases even increases! How can this be so? This is the often overlooked concept of compounding interest. Even if we meet the obligation the best we feel we can, the debt continues to grow in size and severity until we become a slave to the debt. How do you identify that you have become enslaved by mounting technical debt? In an Agile environment, there are signs of debt overextension:
    • If quality in the current product or project is continuing to suffer and the teams are never reaching a point where the existing bug log is diminishing, they are suffering from growing technical debt.
    • When developers are drained because the QA process takes far longer than it should, and the development team calls for a better process to handle testing, this is a sign that technical debt could be nearing a breaking point.
    • When the product is nearing release and only the absolutely required test cases have been addressed, technical debt could be an issue.
    • When the customer is enraged that the product does not perform in an expected manner, that also can be tied to increased technical debt.

    Now that we have identified a few of the signs of technical debt, let’s talk about what we can do to address this before it gets out of hand.

    The first required step to get past any growing debt cycle is to identify each creditor and the amount you owe each one. Once each has been identified, you need to communicate to each one about your plan to eliminate each debt in a concise and planned way. Anyone who has ever dealt with a creditor knows that one of the most difficult tasks is convincing the creditor that they will need to wait until you have paid other creditors and are in a position to pay them their share. The same holds true with stakeholders. We need to help them realize that we will focus on their project and all of the new features and enhancements as soon as possible.

    In the real world, this means letting the customers and stakeholders know that at the risk of slowing down new development and enhancements on current or future projects, the debt must be addressed. This news is never easy to deliver, and people are never happy to find out there will be a delay. However, they are forever grateful once all is said and done and the Agile development project turns out all the better because of the addressed debt. In fact, once the dust settles, the key stakeholders will be even more thankful to have a product or project that exceeds their expectations.

    The next key is negotiating what is reasonable and customary. Often we agree to bite off more than we can chew. We need to only commit to what we can do, and make certain we are transparent in our work in order to allow others to see the benefit in addressing and taking care of our debts. Creditors will never take you at your word if you make promises and fail to deliver. As part of the structured repayment program, you need to meet all obligations.

    Even once all of this has been done, you need to realize that your credit score does not instantly increase. It is through consistently meeting your obligations and eliminating debt over time that your creditors will deem you responsible and extend credit to you. This change does not happen overnight and trust is something that needs to be re-established as soon as possible with all key stakeholders on the project.

    Another consideration is that we need to only focus on the debt that is not forgiven. Corporations do not embrace the concept of technical bankruptcy. There is no debt scrubber that automatically enables agile teams to eliminate all debt and re-structure. Once an organization has been burdened with debt, it needs to work to remove the said debt. The keys to success are simple:
    1. Act NOW!
    2. Identify key areas for repayment.
    3. Enable testers.
    4. Stop forward work as needed.
    5. Make commitments and keep them.
    6. Remain transparent.
    7. Avoid additional debt at ALL cost!
    The lesson learned is that debt is easy to build and hard to eliminate. It takes grit and determination to be successful in the quest to eliminate or drastically reduce debt. As mentioned earlier, the key is to have a plan and stick to it. Snowball to eliminate debt and make certain everyone can see and relish in your success. Reading this blog post could be the first step towards your organization's success.

    The Airport Needs a Runway!

    Saturday, December 12, 2009 by V. Lee Henson CST
    Call me Captain Obvious, but the airport needs a runway. After all, would an airport be an airport at all without one? Even people who fly crop planes will profess that they need a sound place to take off and land from.

    I have come to notice that on more than one occasion, Agile shifts its focus toward all that is happening now without regard for all that will be happening soon. Many teams even choose to forego release planning, as it does not provide the immediate and tangible reward that organizations may be seeking. So how do we continue to focus on the now while laying the foundation for the future?

    The reality of it all is that at some point in the process, we need to put our faith in people and know that what we are asking for will be accomplished. This does not, however, mean that we should not be well prepared.

    Well, we can certainly begin by going back to our airport analogy. Just as we encounter in travel, some airports are more pleasant to visit than others. Even with a safe place to take off and land upon, there is still more to making a great airport. Amenities often make the difference between desirable and dreaded places to stop at on your way to the destination. In an Agile world, this is really much like a release plan. Some are more smooth and others are very rough. When we focus on both the quality of the delivery and arriving on time and under budget, we can draw towards always taking the best path to reach the destination. The best path is often a combination of the one that ensures safe arrival and smooth delivery.

    If we knew a certain flight path consistently provided undesirable results, we would try to avoid it. Yet knowing all of this is true, in a software development world, we often find it hard to adjust even if we have been down the path before. What do we need to do to act in a responsible way and make certain that we are doing what is best for the team, release, organization, and end user? How do we go about making certain the key people are in place to make reaching the final destination an enjoyable venture? Who do we turn to when we need to verify not only that the runway is there for takeoff, but that we can plan on all being for a safe arrival?

    1) Fly often! The more frequently we fly the routes, the more familiar we become with successful delivery.

    2) Plan ahead for landing! Frequent conversation with the control tower helps us land well every time.

    3) Never procrastinate! Do not put off doing what is right!

    4) Deliver early and often. It is the only way we can course-correct.

    There are certain distinct steps which we can follow to help us make certain the takeoff, flight, and landing go off without a hitch.

    1) Identify key resources that will be able & responsible for ensuring the underlying architecture is in place before taking on & committing to the work.

    2) Learn to inspect & adapt, allowing you to follow those routes that have the least turbulence.

    Agile project management and application development should be an easy win for all involved. It is not rocket science to get it all put together, we just need to focus and make certain the runway is indeed in place for us.

    Teams ultimately rely on someone out there to have foundational measures in place for them to build upon. Many argue this is the role of the Agile development manager. Other organizations with a more formal release structure actually build a agile project release team that focuses solely on getting the project built and out the door. In this case, the release manager would be the responsible party. What many small to mid-size organizations that do not practice formal release planning techniques fail to realize is that although no formal role exists for the party responsible for launch, the role does still exist!

    Indulge me and picture if you will for a moment that we were all preparing for the space shuttle to launch. I have visited many organizations who have proclaimed that the runway needs to be part of the actual project, or in one case, that the runway is someone else’s responsibility. I went on to ask if they would feel the same way if they were in the airplane at 32 thousand feet when they learned that the airport they would land at did not bother to build a runway.

    The analogy to practicing agile development has been likened to building a plane while it is in the air. There is even a YouTube video of this process. My question to you remains, how important is it for our airport to have a runway to take off and land upon? Who is responsible for making certain the runway is in place within your organization? After all, without a sound architectural runway, where will your projects take off and land? Who is ultimately responsible for establishing the foundation and making certain all is in order and integrated when it is time to release? Who holds the keys to the kingdom when it comes to making certain all that we build rolls out according to planned expectations?

    Special Delivery - Delivering Agile Projects

    Friday, December 11, 2009 by V. Lee Henson CST
    Many people in the Agile software development community believe that the problems they are facing within their organization are unique to them and their situation. After traveling the globe and listening to groups of all shapes and sizes, I have determined that many of the roadblocks to successful Agile development and implementation are similar in nature from one organization to the next.

    Today, consider it my gift to you to let you know that not only are you not alone in what you are facing, but many other organizations have taken steps to improve the software development process and the way process by which it is delivered.

    Whether you are brand new to Agile in general, or if you are doing an Agile Scrum or Agile XP hybrid, teams have walked this path before and here is what has been identified as the core list of problems they face. Let's just call it the top 3 roadblocks to special delivery: 

    Coming in at Number Three, Lack of Established Definition of Done (Accountability)

    Teams need to take the time to discuss what the differences are between development complete, test complete, done, and final acceptance criteria has been accepted. You would be amazed how many organizations struggle with the lack of this definition and the problems it causes when people figure out that done is not clearly defined and it drives people to work in silos. Lean Software Development and or Kanban Software Development have made attempts to address this issue by establishing clear work in progress limits. The team needs to clearly understand that done is done and what level of expectation has been set for them.

    Not too far behind at Number Two, Inability to Accurately Estimate and or Forecast at both the Story and Task Level

    Let's face it, developers HATE sitting in meetings. They especially loathe meetings that take them away from the coding world to provide estimates that only are useful to the business. We need to find the most efficient and accurate means for people at all levels to estimate, make certain teams agree to the standard, and understand the importance of the why behind the what. Why we estimate and the value it delivers should drive people in any role to use efficient Agile project management software to capture the data in a format that makes it as easy as possible for everyone to be consistent and get back to work.

    And finally, the Number One Problem teams face when trying to deliver, The Product Owner or Product Ownership Cloud lacks the Ability to Precisely Slice & Dice Information From a Traditional Project Management Document Into Meaningful User Stories.

    The role of Product Owner has been so overloaded in the Agile world that many times people do not get the picture of just how much responsibility and accountability ride on this role. In Scrum, I have heard these people referred to as the 'single wringable neck'. This is the person or group who needs to consider value to the organization, need of the customer, & perceived level of effort and complexity to the development team, and with that data need to organize and compile a list of meaningful items to a group of wizards who will shred them even further into tasks. I do not care who you think you might be, this role is NOT an easy one. I am of the opinion the Product Owners need the greatest level of training in order to help them understand why agile, how agile, and be armed with what they need to be successful. 

    So as you are sipping eggnog and eating fruitcake, remember that the success of the Agile project, or the special delivery, lies in your hands.  

    Managing Expectations - The Art of Being a Better Agile Manager

    Wednesday, August 5, 2009 by V. Lee Henson CST
    The question I was faced most with in a recent engagement was, "How do I manage expectations when so many people are asking for different forms of the same deliverable? How can I expect my team to keep that many balls in the air?"

    My reaction, after the shock settled in of course was, what is so out of the ordinary about the expectations that have been set for you and your team? Furthermore, what did you do to retain upward visibility while still maintaining distance between management and the team?

    A recent Leading Agile Post reviewed the role of a manager on the Agile team and even went as far as decrying the demise of the role of manager on many teams while trumpeting the fact that managers will never go away. The final verdict sounded like something I have been saying for some time. After numerous comments and a long twitter thread, all agreed that the role of an Agile Manager needs to evolve. This beckons the question, how do we prepare managers to be recipients of Agile projects and how do we establish reasonable expectations for the team that they may agree to?

    The fact is, managers got to the position where they currently work due to their ability to make great decisions and to assist as many others as possible to reach project completion. When the rubber hits the road, these are the people who are recognized for their ability to get things done! I truly feel that the most often overlooked piece of the puzzle is the re-defined role of the manager as a servant leader.

    I just do not believe the hype about any team who claims to be 100% self organized. At best I have seen teams 10% self organized in a pool of 90% command and chaos! As more and more teams embrace Agile and Lean thinking, teams will need to rely more on solid managers who have redefined their role to fit in the agile schema and will progress by having servant leadership available to remove obstacles when necessary.

    The last remaining thought is how do we get ScrumMasters, Project Leads, Program Managers, Development Leads & Mangers, Product Managers & Owners, Etc. to better understand their new responsibilities on the newly rock solid Agile or Lean team? My guess is that this will require a little more doing than reading, a little more positive re-investment as opposed to scrapping the role all together.

    What we really need is a defined Agile Mentor. We all know the first step is to understand all of the pieces of the puzzle. The next step is to separate the edges from the middle pieces. Next we match like colors, and finally we work as a team to build a high quality puzzle. Why should we treat this any different? We really need to stop for a moment, take a deep breath, regain our focus, and scream to the world that we can be Agile! We can follow Lean principles. We are ready to embrace rapid application development. We understand and can use Scrum Tools and XP tools to help our team improve! We are ready to do what it takes to be successful.