Empowering Agile Teams
•Download as KEY, PDF•
4 likes•3,942 views
The Empowering Agile Teams Presentation has been presented at numerous Agile Conferences and has been VERY well received. Many teams get frustrated due to the lack of understanding of what they are expected to deliver vs what has been perceived. Gone are the days of opacity. Teams are better equipped to handle the day to day workload and are less fearful of commitment in an environment where healthy team relationships are valued.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Empowering Agile Teams
Similar to Empowering Agile Teams (20)
More from AgileDad
Recently uploaded
Recently uploaded (20)
Empowering Agile Teams
- 1. Empowering Agile Teams V. Lee Henson CST 1
- 2. With Great Power Comes Great Responsibility Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 2
- 3. ✤ Founded in 2007 - Salt Lake City, UT ✤ Specialize in Public & Private Certification Workshops & Courses ✤ Deep understanding of Agile & Traditional Project Management, (PMP), RUP, Lean, Kanban, Scrum, (CST), XP, & PMI-ACP ✤ Proven Applied Agile Principles in Software, Hardware, Financial, Insurance, Construction, Medical, Marketing, Legal, Entertainment, Research, Military, Government, Retail, Education, Law Enforcement, and many more... 3
- 4. V. Lee Henson CST ✤ Certified Scrum Trainer ✤ Project Management Professional ✤ PMI- Agile Certified Practitioner ✤ Certified Lean Agile Professional ✤ Motivational Speaker & Executive Coach ✤ Author of The Definitive Agile Checklist ✤ Inventor of Rapid Release Planning ✤ Information Technology / Psychology 4 Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.
- 5. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals & Interactions over processes & tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is , while there is value in the items on the right, we value the items on the left more. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 5
- 6. Agile vs. Plan Driven Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 6
- 7. Scrum vs. Waterfall Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 7
- 8. The What If’s: • All too often embracing even the most basic Agile Principles requires us to address the What If’s: • Agile Teams are nearly as inquisitive as our own children. • We need to say what we’ll do and do what we say in order to be successful. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 8
- 9. More What If’s: • What if we could engage Agile methods without Pain? • What if we prescribe to one Agile Method and follow it to the Letter of the Law? • What if we stop worrying about time and start focusing on end delivery? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 9
- 10. How Does This Apply To What I Do? • Can making even the smallest of changes have an impact on the success of an Agile project? • What can I do in my role to make a difference on my team? • Is it really possible to let go of the reigns without inciting chaos? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 10
- 11. Who’s At Fault? • Once it is discovered that the project is going to exceed the deadline or go over budget, who accepts responsibility? The Executive? Other Management? The Product /Project Manager? The Team? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 11
- 12. Five Levels of Agile Planning: • A great place to start is by analyzing the levels of Agile Planning and assessing if each party played in their respective sandbox. Product Vision Yearly by the product owner Product Roadmap Bi-yearly by the product owner Release Planning Quarterly by the product owner and team Iteration Planning Bi-weekly by the team Daily Planning Daily by the team and individuals Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 12
- 13. Does The Executive Lack Vision? • To what detail should the Executive team be involved in the day to day operational issues of a project? • Does the team have an achievable strategy to execute the vision? • Can executives still feel in power by not using the iron fist approach? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 13
- 14. Sail Well! • Managing Direction • Charting The Course • Use Strategy When Planning • Recognize The Executive is NOT At Fault • Maintain Visibility for the Executive • Do Sail Well! Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 14
- 15. Empowering The Agile Team! Learn To Sail Well! Understanding the Strategy gives the Team the why behind the vision. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 15
- 16. Is It The Product or Project Manager? • To what detail should the Product Owner / Manager have the backlog defined? • Since when is a thorough PRD not enough to get started? • The Project Manager should be trained to assist the team in breaking down a Product Requirements Document, after all, they are responsible for removing impediments right? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 16
- 17. Is It The Team Lead or Other Manager? • Did the Team Lead follow through on being available to assist team members as needed? • Did the Senior Assistant to the Vice Co-Chair Administrative Director over Employee Satisfaction see to it that the teams needs were met? • Did the Development Manager provide the Team with the tools it needed to be successful? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 17
- 18. Empowering The Agile Team! Learn To Sail Well! Manage From the Outside In! When managers use discretion and work from the outside in, this allows the team to remain focused and feel confident that obstacles will be removed in a timely fashion! This also assures the best level of project visibility. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 18
- 19. How Do We Know If They Are Effective? 7 Traits of a Highly Effective Manager: Ability to Manage and Deal With Risk Results Oriented High Energy Team Player Multitasking Ability Improvement Oriented Listen First Speak Second Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 19
- 20. How Do We Know? (Cont.) 7 Traits of a Highly Effective Manager: Ability to Manage and Deal With Risk Results Oriented High Energy Team Player Multitasking Ability Improvement Oriented Listen First Speak Second Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 20
- 21. If Not The Leadership… • Once all the dust has settled, it is easy to determine that the leadership is not generally responsible for the team failing to complete the project they committed to. • Could it possibly be… Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 21
- 22. It Must Be The Team? • Could it possibly be the team at fault here? • What could the team have done differently? • Could this be the result of multiple external factors affecting the team? • Is it possible that they really did not have a clear understanding of what they were committing to? • At what level should the team be held accountable for the level of work they committed to? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 22
- 23. Is The Team Being Effective? The team embraces the truth The team works in a culture that supports learning The team has the authority and makes regular decisions The product owner is consistently available to the team and the team takes advantage of it The team has a GREAT ScrumMaster The team meets daily and is aware of current & upcoming projects Everyone required attends regular Agile Meetings The team effectively uses the retrospective to inspect & adapt The team has set the rules and understands the definition of done The team is accountable for the work they commit to and they take that commitment seriously Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 23
- 24. Empowering The Agile Team! Learn To Sail Well! Manage From the Outside In! Enable the Team to follow the 10 keys to effectiveness! The 10 keys listed on the previous slide are a critical path for the team to follow in order to be empowered and trusted. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 24
- 25. Is The Team Empowered? Efficient Motivated Productive Organized Well Managed Engaged Responsible Energized Dedicated Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 25
- 26. Team Empowerment ‘Moments’ • Every team has a moment where they realize that they are an empowered team • It is usually like a light switch going on • The stakes become much higher and the value & unity of the team greatly increases • People will see, feel, and ‘smell’ the difference in an empowered team Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 26
- 27. Smell Of An Empowered Team • Collaboration – If the team works in silence, you will get what you hear as a deliverable • Teambuilding – The team should work together and act like a team • Accountability – The team should stand tall and be accountable for both completed and uncompleted work • Productivity – The team should not be measured by the duration of time they put into building the widget, but by the quality of the end result • Quality Demos – Teams should be proud to showcase their work. If they are not, a different problem could be brewing Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 27
- 28. Foul Team Smells • Loss of Rhythm • Talking Chickens • Missing Pigs Copyright 2003, Mike Cohn Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 28
- 29. The REALLY SMELLY Team • Persistent Signatures • Project Manager or ScrumMaster Assigns Work • The Daily Meeting is NOT for the Team • Specialized Job Roles Copyright 2003, Mike Cohn Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 29
- 30. Pitfalls and Warnings of a Damaged Team Lack of Energy No regard for commitments Team more worried about time than productivity Team does not want to demo Team finds daily standup meetings useless Team Frequently overestimates or pads estimates Team becomes dejected Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 30
- 31. Empowering The Agile Team! Learn To Sail Well! Manage From the Outside In! Enable the Team to follow the 10 keys to effectiveness! Keep the Team Smelling Fresh! Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 31
- 32. How Do We All Win? Stop the finger pointing! Work together as a cohesive unit. Play in our own areas of the planning playground. No time games. AND MOST IMPORTANTLY… Realize as a team that: “With Great Power Comes Great Responsibility!” Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 32
- 33. Empowering The Agile Team! Learn To Sail Well! Manage From the Outside In! Enable the Team to follow the 10 keys to effectiveness! Keep the Team Smelling Fresh! Start Today! Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 33
- 34. ✤ You now hold the keys to success! ✤ You have been educated and empowered. ✤ Visit often and drink from the well! http://www.agiledad.com/ Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 34
- 35. Thank You! Lee@AgileDad.Com - Twitter @AgileDad - LinkedIn leehenson@gmail.com Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 35
Editor's Notes
- \n
- \n
- \n
- \n
- Principles behind the Agile Manifesto\nWe follow these principles: \n\nOur highest priority is to satisfy the customer through early and continuous delivery of valuable software. \nWelcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. \nDeliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. \nBusiness people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. \nThe most efficient and effective method of conveying information to and within a development team is face-to-face conversation. \nWorking software is the primary measure of progress. \nAgile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. \nContinuous attention to technical excellence and good design enhances agility. \nSimplicity--the art of maximizing the amount of work not done--is essential. \nThe best architectures, requirements, and designs emerge from self-organizing teams. \nAt regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. \n
- \n
- \n
- The What If’s? are quite an interesting bunch. I remember the day when my children first stated asking this very question. \n\nCan I ride my bike to the park? …No, not now\nWhat if I invite a friend to come along? No = What she really hears = You do not trust my friends?\nWhat if I ride slow? No = What she really hears = You feel I am not safety conscious?\nWhat if I walk instead of ride? No = What she really hears = You do not even trust me to walk across the street?\nWhat if I just don’t go? What she really hears = You do NOT trust me at all? \n\nAgile teams feel very much the same way when we do certain things in the workplace. \n\nWhy did this project fail? Why did we deliver late? Why did we exceed our budget? \nThe plan to execute did not match the strategic vision of what the customer wanted = The Executive vision was not accurate and / or not communicated well.\nThe Management team failed to provide me with the tools / resources I needed to do the job to the best of my ability. = It’s a managers fault.\nThe requirements were not clearly defined or, we did not have a clear interpretation of what was to be done. = It’s the Product Owner\nWe had too many outside interferences and were constantly putting out fires. = It is the Project Manager or ScrumMaster\nWe simply failed to get it done. We the team take full responsibility. \n
- Let’s put this in a different light: \n\nTeam: Will you support us in our efforts to complete this project using Agile Principles? \nBoss: Sure, if that means I get more done in a faster amount of time with fewer resources. \n\nAs the boss walks away he dreams of all of the last minute things he can toss into the fire and get them done quicker than ever before!\n\nThere is still so much left to explore when it comes to what if’s…\n\n \n\n\n\n \n
- Many times we question the what if’s and how they apply to what I do. One of the very earliest projects I had the privilege of working on involved having an active Marine General as the end customer. For those of you without military experience, we are talking about the most impressive form of command and control management ever known to exist. The youngest Marines are educated by their senior officers based on years of experience backing every decision made for them. \n\nOne might go as far as to say that by letting go of the reigns, any complex project would enter a vortex of hopelessness and spin out of control ending in a fiery crash. I am here to state to you all this is simply not the case. In fact, it is almost entirely the opposite approach that works best. Once a team understands what they are being asked to complete and why, they are generally more successful than teams that rely on the command and control structure. My what if conversation went something like this:\n\nWhat if we didn’t jump into this Agile thing feet first? \nWhat if I just kept a running list (backlog), of the things I felt should be worked on first?\nWhat if we met daily for our recap as opposed to meeting once a week for several hours? \nWhat if I could provide you with samples of completed work every 2-4 weeks and let you inspect our progress? \nWhat if I could assure you that by placing confidence in the members of the team that the project stands a higher chance of being completed on time and within scope?\n
- Let the finger pointing begin! This is the place where the rubber hits the road. It is especially easy for people to quickly assess the situation and identify anyone else who was the cause of the debacle. This is the greatest point of contention amongst teams. This is also the greatest opportunity for the team to retrospect and adjust in order to prevent this from happening in the future. \n\nThe key here is to stop pointing fingers and start searching for clues…\n
- \n
- Unfortunately, the first group looking to hold someone responsible for project failure is the executive team. Are you prepared to give a complete report on why the team failed to deliver? Have you considered doing a demo of what has been completed? What reaction might you expect from the executive team? What could we do to alleviate the pain in the future? \n\nWhat if we had the ability to promise both on-time delivery and precision metrics?\nWhat if we could help the Executive understand their role in the Agile process?\nWhat if we had the Power to help frame the Vision? \n
- When I say the term Sail Well, what specifics come to mind? Some would consider this great advice, but the question remains is this great counsel for an Agile team? What exactly does sail well mean? Does it provide concrete direction? One could argue that with direction already solidified, this advice could be the first indication of an executive maintaining control of the vision while allowing the team to chart it’s own course. \n\nWe all know there is more than one way to reach the final destination. This may be why I selected to use the word Strategy in lieu of vision. Vision indicates a dream or long term goal that has suddenly become within reach. Strategy includes vision and careful planning with the rest of the crew to make certain the ship remains on target. Charting the most desirable and or efficient course becomes the next step in the process. \n\nConsider the difference between basic Vision and having a Strategy in place. Take the time to find the most strategic solution. Now is also a great time to realize that the executive is not at fault. Should the strategy not be clearly outlined, someone should be speaking up! It is the Team’s responsibility to provide the needed visibility to the executive at every level in order to assist them in maintaining the project at their level. \n\nPart of being an empowered team is Learning to Sail Well! \n
- \n
- The Second round of finger pointing award goes to the Product Owner and Project Manager. \n\nDid the Product Owner do his or her job of breaking down the Product Requirements Document? \nWere all of the stories in the backlog clearly defined?\nDid the Product Owner share in the Strategy set forth from the vision? \nWas the Product Owner a true representative of the customer? \nWas the Product Owner available to the team? \n\nWas the Project Manager able to remove impediments in a timely way? \nDid the Project Manager work with the team to help them plan for what their capacity would hold? \nDid the PMO Organization pay enough attention to this high profile project? \n\nCould anyone have assisted the team in their quest to do better? \n\nOnce again the team needs to see that although these individuals could have contributed to the team’s inability to perform, neither of these individuals should be held accountable. \n
- Are you looking at me? This is where the real finger pointing begins. The fact is we need to assess the level of management oversight vs. the level of helpful management. This follows the Servant-Leader Principle. It is far easier for managers in these roles to stick to removing impediments and steering clear of the everyday nature of the work the team does. \n\nLikewise, a good Product Owner / Manager can learn to stay focused on the customers needs and the direction the product takes to get there. The Project Manager should be focused on the success of the team and should really work to gain the team’s trust. This role should serve more as a consultant and mentor. The greatest fall any manager level position could take is to dive too deeply into roles outside of their own. \n\nThe fact is effective managers manage from the outside in. Worry about the bare minimum that you need to in order to insure the project’s success. Focus on removing impediments and providing the team the tools they need to be successful. In return you will receive the greatest level of visibility into the project. \n
- \n
- The signs of an effective manager are a little more tough to outline on an Agile team. Not because they are doing less demanding work, but they are doing less work and more inspection and adaptation. Instead of steering a team to turn right, turn left, move slower, move faster, etc. the manager is spending more time removing the roadblocks and being a true team player. This does not mean they are spending great amounts of time analyzing things at the same level as the team. It does mean that they are taking the time to understand exactly what needs to be done and using that as a building block for team success. \n\nAbility to Manage and Deal With Risk - Every decision an Agile team makes involves some level of assumed risk. It becomes the managers responsibility to assess the dangers ahead and steer the team on the most safe route. It is also the responsibility of the manager to highlight what facets of any given project are at risk.\nResults Oriented - The Agile Manager worries a lot less about how many hours you have put in this week and worries a lot more about what you have produced as a result of the effort expended. This is not to say that we can completely do away with time as a fixture, there is always a cost to each output. This in essence says that our focus will be more directed to the output than the throughput. \nHigh Energy – Nothing is worse than the ‘donut supervisor’. If the manager in question is never around (especially from a product perspective), that is an indication that you need to get someone involved that is a bit more excited about the teams’ accomplishments. A GREAT manager is engaged.\nTeam Player – The Manager of an Agile team should truly feel like they are a part of the team! Although they may not be allowed to constantly change requirements or verbalize why something is critical to be squeezed in, they are still a core part of the success of the team. In many cases they represent the team to the customer and or the customer to the team. \n
- Multitasking Ability- The Agile Manager MUST be able to multi-task and be aware of the status, forecasted release, and daily progress of each project / product they are managing. This does require complete visibility into the project allowing the manager a chance to view information from a comfortable distance. \nImprovement Oriented- Every Agile team thrives on the inspect and adapt model. This means they expect you to be at their demo. They expect clear and consistent feedback. This means they expect the correct resources to get the job done. \nListen First Speak Second- Silence is GOLDEN! Listening often clarifies what someone is really trying to say without you ever having to say a word. A great manager is always a great listener first. Once they have a clear understanding, then it is their time to speak and propose best practices. \n
- After reviewing the characteristics of dynamic leaders, it is easy to discover whether the leaders in your organization are doing an effective job. If the leaders are following most of what we have listed, the problem could lie elsewhere. There is still the chance that someone else in your organization could be responsible for the team not being as efficient as possible. Who else could it be? What else could be the root cause of the problem? \n
- I already know what you are thinking… He did not just let management off the hook and point the finger at the team. The fact is, in more cases than not, the team could have done something differently in order to help make certain the ship continues to steer towards safety. What more could the team have done? How do we know if the team is being effective? \n
- On occasion the truth may be too much to handle. The team needs to deliver the truth first and always in order to maintain high visibility and to become trusted amongst management. \nWork should never be assigned or delegated. The team may have a subject matter expert on the particular story at hand, but cross pollination is encouraged. Teams should take advantage of every opportunity to learn and educate each other. Over time the team’s velocity will increase as a result. \nThe worst decision that can be made is no decision at all. Make and embrace decisions. Your leaders will thank you for it. \nTeams really should be having items signed off on throughout the iteration. When a great product owner or manager makes themselves available to you for questions etc., make certain you set aside time to regularly demo what you have internally to prepare for the external release. \nNo team can be successful without a champion to remove the impediments and assist the team in running interference. This leader should be both a champion of the cause and a great facilitator. \nRegular short meetings have proven time and time again that they are far more effective than the once weekly status updates. Keeping on top of the information daily provides for crisper communication and increased visibility.\nAll committed parties should attend every team meeting. The meetings should be short, time boxed, and to the point. (This includes the retrospective)\nThe team should set rules, define done, and make & take commitments seriously. \n
- The team embraces the truth\nThe team works in a culture that supports learning\nThe team has the authority and makes regular decisions\nThe product owner is consistently available to the team and the team takes advantage of it\nThe team has a GREAT ScrumMaster\nThe team meets daily and is aware of current and upcoming projects\nEveryone required attends regular Agile Meetings\nThe team effectively uses the retrospective to inspect & adapt\nThe team has set the rules and understands the definition of done\nThe team is accountable for the work they commit to and they take that commitment seriously\n
- Efficient – performing or functioning in the best possible manner with the least waste of time and effort; having and using requisite knowledge, skill, and industry; \n\nMotivated – move to action; impel\n \nProductive – having the power of producing; generative; creative\n\nOrganized – to put (oneself) in a state of mental competence to perform a task\n \nWell Managed – to bring about or succeed in accomplishing, sometimes despite difficulty or hardship\n\nEngaged – busy or occupied; involved\n\nResponsible – answerable or accountable, as for something within one's power, control, or management\n \nEnergized – to give energy to; rouse into activity\n\nDedicated – wholly committed to something, as to an ideal, political cause, or personal goal\n
- Every team can recall the moment they felt empowered. Use the space below to record your own empowerment story:\n
- In 2003 Mike Cohn stated: “Even with Scrum things can go wrong. As diligent ScrumMasters it is our responsibility to constantly keep an eye on our projects and look for small problems before they can become big problems. In his book Refactoring, Martin Fowler introduced the term smell to refer to something that may not be right. Just because something smells doesn’t mean there’s a problem; it does mean, though, that further investigation is warranted.” \n
- Loss of Rhythm\nSymptom: Iterations are not always the same length.\nDiscussion: On a well-executed project the team establishes a natural rhythm. Each sprint is the same length. Each sprint starts with a Sprint Planning Meeting where requirements are discussed and the sprint planned. Each sprint concludes with a Sprint Review where the team demonstrates a potentially shippable product increment. In-between the project rhythm is supported by daily scrums. If sprints are sometimes two weeks and sometimes four weeks then this natural rhythm is never established. Sprints then begin to feel like arbitrary units of time with endpoints selected more by outside forces (perhaps political or competitive) rather than designed to enhance the overall productivity of the team. When sprint duration is allowed to vary teams have a harder time selecting the right amount of work for the sprint backlog, which may result is less commitment to completing all of the items in the sprint.\n\nTalking Chickens\nSymptom: Chickens attending the daily Scrum are allowed to ask questions or make observations. Discussion: During the daily Scrum the only participants allowed to speak are the pigs (those committed to the project); chickens (those involved but not committed) may attend and observe but are not allowed to speak. Allowing chickens to talk can be a slippery slope. If a chicken is allowed to make a comment one time (when the comment is useful), how do we later prevent a chicken from commenting (when the comment may not be useful)?\n\nA few months ago I took my young daughters to a local fair. The line for one ride led up to a short flight of stairs at the base of the ride. No one was allowed on those stairs, but many of the young kids wanted to sit on the stairs while waiting. The ride operator, though, held firm to her rule of no one on the stairs. She told\nthem, “If I let you sit on the first step soon you’ll be on the second step and then the third step.” Clearly sitting on the first step would not have endangered any riders but the stairs were an obvious delineation and the ride operator used this as her simple rule. Not allowing chickens to talk during the daily meeting is one\nof Scrum’s simple rules. Of course one comment from a chicken may not hurt—but it will lead to others and then there will be no easy place to draw the line.\n\nMissing Pigs\nSymptom: Not all pigs attend the daily Scrum meeting.\nDiscussion: When I started working there was no such thing as “flex time.” Every company had a starting time and everyone was expected to be at work by that time. Flex time, combined with the nocturnal habits of many software developers, makes it common to have some members of a team arrive at 11:00 am,\nor even later. I worked with one team who had nicknamed one programmer “Captain Midnight” because he quite literally came to work around midnight each day.\n
- Persistent Signatures\nSymptom: The wild fluctuations shown on a team’s initial sprint burndown charts continue to be seen in\nmuch later sprints.\nDiscussion: In Agile Software Development with Scrum, Ken Schwaber and Mike Beedle write about each team having a unique signature—some teams bring in too much work at the start of a sprint, others bring in too little, and so on. However, it is important that a team learn from its past sprints. For example, suppose a team of five started the last sprint with an estimated 600 hours of work (the first point on their sprint burndown chart). Midway through that sprint they realized they were attempting too much and worked with the Product Owner to remove 100 hours of work. Now, in planning the next sprint they again want to bring in 600 hours of work. They need to look at that and answer for themselves why they think they can achieve 600 hours of estimated work this sprint when it was too much last sprint. Over time, as teams learn about themselves and their project their sprint burndown charts should lose the wild variations that may have existed in initial sprints and begin to somewhat approximate the idealized straight line. If this trend is not apparent for a team then they are missing opportunities to learn from their\nown past performance. \n\nScrumMaster Assigns Work\nSymptom: Work is assigned by the ScrumMaster rather than signed up for by developers.\nDiscussion: Self-organization is one of the underlying principles of Scrum. When a ScrumMaster assigns work it undermines the responsibility developers assume when they are allowed to self-organize around the achievement of a goal. The real danger here is that even an occasional assignment from a ScrumMaster can\ndo a lot of damage. Teams need to feel completely in control of their own work. \n\nThe Daily Scrum is For the ScrumMaster \nSymptom: The Daily Scrum feels like it is a status update from the team members to the ScrumMaster. \nDiscussion: Sometimes the daily Scrum begins to feel as though it exist solely for the ScrumMaster. You’ll see the ScrumMaster furiously scrawling notes about who committed to what work and why some other task wasn’t completed. Daily meetings like this take on the feeling of the status meetings of other development processes. There are two main purposes of the daily Scrum and neither is to provide status information to the ScrumMaster. The first purpose of the daily Scrum is to provide a coordination mechanism for everyone on the project. Once a day it can be very useful for everyone to hear where everyone else is. Ideally there are many hallway or random conversations throughout the day but those don’t usually include the full team. During the daily Scrum everyone gets a sense of where everyone else is.\n\nThe second purpose of the daily Scrum is for each team member to make commitments in front of his or her peers. When a developer answers the “What are you going to do today?” question she is making a commitment to her peers, not to the ScrumMaster. At the next meeting if that commitment has not been fulfilled it is not the ScrumMaster’s role to say, “Tsk, tsk, Lucy, yesterday you told us you’d be done.” If Lucy said she’d be done and isn’t she probably feels bad enough. She knows what she told her peers and she knows if she didn’t finish because of random bad luck, a lack of effort, misunderstanding the size of complexity of the task, or any of a myriad other reasons.\n\nSpecialized Job Roles\nSymptom: A project team has highly specialized job roles or descriptions such as Architect, Designer, DBA, or Tester.\nDiscussion: Scrum teams need to have a “we’re all in this together attitude.” This can sometimes be undermined if a team has specialized job descriptions or roles. For example, if a team includes a dedicated “tester” then this may give the rest of the team an opportunity to shirk the responsibility to test. With the highly complex technologies of the world today it is too simplistic to think that everyone can be a DBA and everyone can write server-side J2EE or .Net code. A successful Scrum team does not need to be comprised entirely of generalists. However, for a team of specialists to be successful each specialist must accept general responsibility for the system as a whole. I may not know how to solve our project’s most intricate Oracle problems but I’m going to do whatever I can to help, which may simply include taking on some of our database specialist’s other responsibilities to free her to solve the complex problems. \n
- These seven signs are visual indicators that the team in question is sincerely in trouble! \n\nAny time the team shows lack of energy or enthusiasm for their work this is an indicator that they feel like they are on a death march or they feel a sense of hopelessness. This should be addressed as soon as humanly possible. \nWhen the team begins to just commit without regard to end a meeting, this is an indicator that their voice is not being heard. \nWhen the team is more worried about finishing ‘80 hours’ worth of updates every two weeks instead of dedicating as much time as they can to the finished product, they feel like they are being micro-managed.\nWhen the team does not want to demo, this is an indicator that they do not accept ownership for the work they were most likely assigned. The team needs to experience personal ownership and accountability in order to feel successful. \nWhen the team is not getting benefit from meeting daily, that means they are lacking reporting discipline. In all my years I have NEVER encountered a team that did not benefit from a brief daily meeting. This is also a warning signal that they do not feel accountable for their work. \nWhen teams pad, this is a sign that they feel like they have to pad. In other words, they do not feel like they are receiving requisite attention for the work that is getting complete. I have even had a team member mention to me that padding was the only way he felt he could take a break. \nWhen the team straggles into a meeting one by one looking at the floor and not talking to each other… This is a BAD sign. This means you missed one or many of the other six and need to take action now before monster.com becomes the teams most visited website. \n
- Collaboration – If the team works in silence, you will get what you hear as a deliverable\nTeambuilding – The team should work together and act like a team.\nAccountability – The team should stand tall and be accountable for both completed and uncompleted work\nProductivity – The team should not be measured by the duration of time they put into building the widget, but by the quality of the end result, the widget \nQuality Demos – Teams should be proud to showcase their work. If they are not, a different problem could be brewing \nMeaningful Retrospectives – Empowered teams look for EVERY opportunity to inspect and adapt\n
- \n
- Do not wait to make this happen! The sooner you start, the happier your team will be. We all realize that as the team becomes more accountable they will be more trusted. As the team becomes more trusted, they will be looked upon for their work and not the amount of time it took them to get there. The team succeeds or fails together. Now that I have given you the keys to power, it is up to you to be responsible. Failing to follow through yields a release of power. \n\nAdherence to basic Agile principles is the key! \n
- \n
- Please send me your feedback and or thoughts. \n