Viewing Posts by William Krebs
Tracking Burn-down Progress
| Agile teams often rely on burn-down charts to show how much work remains in each two-week sprint. The starting point represents the total work to be done and ends at zero when it's finished. There's no detailed plan of how much work is done each day -- teams just draw a line from start to finish. But two problems can arise: 1. Teams get used to collecting data, but forget to interpret and take action on it. 2. Executives may look at the graph and become concerned if the actual numbers don't track precisely to the projected line. So how do you know when to be concerned versus when the numbers are varying normally? An average of 20 percent variance is a good rule of thumb. Anything less is a false alarm. Anything more demands attention. Here are some models I've created of possible scenarios, but in reality, progress is more of a wandering curve. The vertical axis shows how many hours are left and the horizontal axis shows how many days are left. The straight blue line represents the planned amount of work left each day in hours, while the red line shows the actual hours left. Case 1: Under the line The team consistently finished more work than expected. Does this represent an error in estimation or natural variance in the system? Case 2: Above the line -- but okay The team is running behind, but is close enough that it will still complete the work for the iteration. Case 3: Above the line -- in trouble The team is so far behind, it must stop and take action to address the problems or re-plan the work. This progress line is a powerful warning signal. How do you use burn-down charts? |
Are We Self-Organized Yet?
Categories:
Agile
Categories: Agile
| The Agile Manifesto calls for teams to be "self organized," but this is often easier said than done. The manifesto states, "The best architectures, requirements and designs emerge from self-organizing teams." This can be a challenge for some team members. Project managers on traditional teams may be more comfortable working alone than working closely with each other, as Agile demands. So how can they implement self-organization? Here are some ways to know if your team is self-organized: 1) Actions taken after Scrum meetings. Good teams have frequent exchanges during the daily standup meetings. Are people mentioning problems and are teammates offering help? Do members take collaborative actions to solve those problems after the meeting? Watch for teams where people remain individually focused. 2) Flexible roles. Members on self-organized teams will be able to support each other by handling tasks outside their usual specialties. 3) Communication. Self-organized teams will use immediate forms of communication: text messages, instant messages, phone and even walking to each other's desk. 4) Role of the project manager. On self-organized teams, the project manager will spend less time assigning work, and more time facilitating the team as work is "pulled" from the backlog. 5) Role of the manager. The project manager's boss does less hands-on direct planning, but more coaching, rewarding and gathering resources for the team. Teams may also benefit from better understanding of diverse personality styles (See my post: Making the Most of Team Differences). The benefits of self-organization are not just a better product. You will sense renewed energy in the team. Is your Agile team self-organized? What benefits do you find in that structure? |
An Agile Team's Recipe for Success
| In my experience coaching teams, I've found that some stand out in terms of productivity. Cathy Baker, PMP, is the certified ScrumMaster for one of my favorite agile teams. She has managed projects for 11 years, currently in the healthcare industry. Her team is a good example of a group that has learned from practical experience. I interviewed Ms. Baker to get her take on how her team improved efficiency and quality. Your team seems to really 'get' agile. What do you feel are the key success factors for your team? Ms. Baker: Strict adherence was certainly one. Rather than trying to bend the rules we were learning, we followed the practices by the book at first. We are gatekeepers of the process with each other. It is not me, the ScrumMaster, doing it. The whole team monitors the process. They challenge each other with questions like, "Is that what we should be doing?" So you didn't stray from the agile books? Ms. Baker: After we became fluent in agile, we changed our stand-up meeting to go task by task instead of person by person. Good retrospectives were also a key factor. Creative ideas helped us take agile beyond where we started and made it a custom fit for our team. So your team didn't start out as agile experts? Ms. Baker: Oh, no. They weren't born that way. They were tried and true waterfall folks. They were used to heavy plans that left little flexibility for change. Most of them had 15-plus years experience each using waterfall methodologies. What prompted you to go agile? Ms. Baker: Management wanted development to go faster and to produce more in less time. Was there resistance to agile at first? Ms. Baker: Yes. We heard "This is not going to work," "We'll be back to waterfall in six months," "Why are they making us do this?" "This is just a fad that's going to pass." What benefits do you find using agile? Ms. Baker: Agile is definitely more fun because we are so self-organized. We are more efficient and have moderately increased our quality of projects. We have such high buy-in among the team now; people get more and more out of the process as time goes on. I notice you use a physical taskboard to track tasks? Ms. Baker: It works. It's clear. 'If it isn't broke, don't fix it.' Of course, the taskboard has been a handicap with the one team member who meets with us by phone, but she can see a related spreadsheet. I do feel like one of our reasons for success is because all but one of us are located in the same place. Most members have worked on the same team together and average eight years of experience. There is a lot of respect. Thanks, Cathy for sharing your recipes for success: adherence, retrospectives, taskboards and self-organization. |
A New Take on Standup Meetings
Categories:
Agile
Categories: Agile
| Short daily meetings are a cornerstone of agile project management. Team members usually address three questions: 1. What did they do yesterday? 2. What will they do today? 3. What roadblocks stand in their way? Some teams use an alternate format with a quicker flow. Looking at a task board, an appropriate team member says how many hours are left on each task. Once a task is complete, it's moved to the next state (test or done). If the team has capacity to take on more tasks, another one is pulled from the queue. At the end of the meeting, the team can see if someone needs work, can help another person or determine if there are any hindrances. This meeting format emphasizes little wins as tasks are moved from state to state. People get some positive feedback and congratulate each other -- which is important to the long-term functionality of the team. This type of meeting also keeps people from discussing work not related to the teams' tasks. It still allows space to discuss impediments and team utilization -- but only if necessary. Teams using this approach can complete their daily 15-minute standup meeting in 10 minutes. More importantly, there's a feel of energy and drive in such meetings. The three-question format is tried and true. If you find your meetings feel sluggish, give this format a try. You may find it turbo-charges your meetings. Which approach do you prefer? |
Tools for Distributed Teams
Categories:
Agile
Categories: Agile
| It's rare to find project teams that are collocated anymore, including agile teams. People are increasingly working from home, remote locations or overseas. Traditional communication tools like teleconference or e-mail are often insufficient due to a lack of a sense of presence. But a new generation of tools offers better possibilities for teamwork. These new tools aim to provide effective communication and help remote agile teams by simulating a visual environment. 2-D: Tools such as Sococo show the layout of an office floor and represent people by dots. Each team member gets an office. When people visit each other in the same room, voice, audio as well as text messages are limited to that room to indicate who is speaking with whom. They can also share screens easily. 2.5-D: Some tools show static 3-D representations of a space. The pictures do not move, but participants feel like they are at a live event. They can navigate to rooms to attend events of interest and gather with people of similar interest in chat rooms. Unisfair and On24 are examples of this, and have been used effectively for trade shows. 3-D: The next class of tools uses an avatar of each team member in a 3-D space. But many have different features that allow different uses. Most use a stereo sound that fades with distance to highlight who is speaking by reducing the volume of their voice according to distance. Venuegen is designed to get people running quickly and to show body language through common gestures. A variety of settings can be chosen, ranging from an office, war-room, classroom or trade floor. Each contains screens to show presentations, web pages, documents, video and images. Teleplace extends this model by allowing team members to post notes on the wall, display documents, and also to co-edit spreadsheets simultaneously in 3-D breakout rooms. This platform is popular with government teams for training and simulation. Teleplace and graphically rich environments based on the Unity3d toolkit allow importing of professionally created models and settings. 3-D programmable: some platforms allow users to create custom objects with easier modeling tools, or even script interactive behavior. Opensim based environments are popular with universities, and platforms such as the Unity3d toolkit support more advanced programming. No matter which tool agile teams use, many of these platforms create engaging venues for training and collaboration. Seeing visual representations of yourself, others, documents and data allows new ways to erase the distance between today's dispersed teams. Pictured: A sample screenshot from the Sococo tool. The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI. |





