More posts in Agile
Here are five ways agile and Scrum techniques can curtail project quality risks:
1. All practitioners must review project requirements with the client.
In agile, the "user story" is the basic building block for agile requirement lists. A formal "acceptance test" is an integral part of that user story, as is explicitly reviewing it with the client to verify you have customer concurrence on the deliverable.
2. Agile teams collaborate while creating project components.
Inspections or pairing can prevent up to 50 percent of possible defects, according to research I conducted with colleagues. In addition, collaborating helps team members share other knowledge about the product or tools used to meet project needs at a critical stage.
3. Authors create a consistent set of verification measures.
Ideally, this takes the form of automated verification tests designed to catch missing functions or incorrect product behavior. These tests are run by the original author, as a sort of control against variables, and also used for regression testing by other team members. Yet even if a project passes these tests, it's also crucial that the product components are streamlined from the get-go so they can be easily maintained or extended in the future. This is called "refactoring."
4. Quality teams test small project deliverables as they are written.
Since the deliverables have been inspected or pre-tested, at this point you should expect few errors.
5. Feedback from a demonstration.
Agile teams hold demonstrations for their stakeholders, showing items completed since the last demonstration. The key is to elicit feedback from stakeholders and use it to improve the product. This provides one final chance to confirm that what the team produced was what the customer wanted. In this way, ideas and changes can be addressed before the completion of the project.
In addition to the following checklist for agile and Scrum risk reduction, it never hurts for teams to employ risk lists to further improve project performance:
- Client review of each acceptance test
- Team collaboration in inspection or pairing
- Test automation by the author and refactoring cleanup
- Independent testing by the quality team
- Demo to the client
How else do you think agile helps mitigate risk? What steps do your teams take to mitigate risk?
Read the Organizational Agility report for an in-depth look at how agile organizations increase their success rate on new projects, even in a volatile global economy.
The survey found that more than 25 percent of respondents now use agile project techniques frequently, and that number is likely to keep moving up. The survey also found that in successful organizations, 68 percent of projects meeting original goals and business intent often used agile project management.
But how does agile apply not just to teams but to organizations as a whole?
When an agile adoption is new, the focus is on training. When teams have been trained, shift your emphasis to fostering a community of agile practice in your organization. As agile matures, the metrics will expand beyond how many people use agile. The metrics will start to verify that agile benefits are beginning to be realized.
These tips can help an organization assess the strengths and deficiencies of its agile teams:
1. Instead of asking about one team's remaining work at the end of an iteration, look at the amount for unfinished work for all teams in your organization. This can tell you who needs more coaching.
Graph the remaining work for each team every two weeks, for example. Can you see which teams need more help? Can you find the average slope for both successful and unsuccessful iterations? Ideally, we start at 100 percent work planned on day one, reach 50 percent in the middle and have 0 percent left at the end of the iteration.
2. Determine if all of your project teams are adding requirements. This can tell you if you are implementing the letter of agile, but not the intent. Strong agile teams will capture some competitive advantage of timely requirements, but will control scope change to not lose focus.
3. Get a pulse on impediments and retrospective actions for all teams. This can tell you if teams are implementing continuous improvement and facing risks head on.
Asking these questions at an organizational level may not be natural at first. But when encouraged, it can reveal a new perspective on which teams are actually leveraging agile as they mature on their path to adoption.
What are your thoughts on organizational agility?
To discuss Pulse of the Profession on Twitter, please use #pmipulse.
See more on the Pulse of the Profession.
While I am not particularly new to the concepts of agile, I was looking forward to learning the extended basic agile concepts, frameworks and skill sets, and learning to apply those skills.
Surprisingly, I understood more of Scrum than I thought I would and realized I was already implementing some agile principles into my waterfall projects. Most importantly, I realized that the debates surrounding waterfall versus Scrum may just be full of hot air.
The focus of those arguments is that one approach is categorically better than the other in all circumstances. That couldn't be farther from the truth. Traditional and agile frameworks are neither better nor worse than the other. But, either could be completely disastrous for a project if applied broadly.
One of the most important ideas I took away was the idea of 'appropriateness.' Scrum is about finding the right level of planning, documentation, velocity of task output, cost and schedule -- and not just per project, but per team. It's not about what is 'best,' but what is appropriate and suitably fits the set of circumstances at hand.
I began to think that if all project managers embraced this idea of using an appropriate approach instead of the perceived 'best' approach, projects could potentially get along much better than they currently are.
I think that what is appropriate for a project could be waterfall, it could be agile or it could be a hybrid. And that would mean project managers would have to be well versed in all kinds of approaches and understand several project management languages.
At the end of the two days, and after an online assessment, I became certified as a Scrum master, but I think I became more than that. I got better at being able to identify what a project needs and what a team needs. Now, I have a few choices as to which approach is appropriate to meet those needs and ensure success.
Do you think there can be a hybrid?
If that point is missed, teams may struggle during the initial high-level estimates.
To avoid that problem, I suggest that at the beginning of a project, teams do a rough estimate of each requirement. One common estimating technique includes "planning poker," also called Wideband Delphi.
In planning poker, each team member secretly picks a number representing how much effort or complexity they think is involved in a given requirement. The numbers then are revealed. The person with the highest value explains to the team why it is hard. The person with the lowest value explains why it is easy.
After no more than two minutes of discussion, the team votes again. This process is repeated until the team reaches a consensus or it discovers there is not enough information to estimate this requirement.
The problem arises when teams blur the focus between the low-level estimates for a two-week iteration and high-level estimates for the release. Low-level estimates are more precise because they split a requirement into several tasks, estimated in hours. By contrast, the high-level estimates are in more abstract relative "points."
Some teams incorrectly attempt to identify predecessor dependencies in high-level estimates. They can also spend too long trying to refine the estimate or silo work between sub-teams to make two estimates for the same requirement.
This detracts from the goal of being able to estimate a large pile of requirements quickly and at the beginning of your project. Remember, there is plenty of time to deep dive later.
How long does it take you to estimate your project?
There are three common patterns to look for in a burndown chart. When progress stalls, the line becomes flat. When work is added, the line shoots up. And sometimes, the rate of work slows and floats above an ideal trend line.
Let's look at some baseline data, reflect on the meaning revealed by the charts and see where teams can improve.
The following burndown charts show how many task hours are left for the team. The goal is to drive the remaining work down to zero by the end of the time-box.
We'll start with a graph of three iterations completed by one team in two weeks. Sprint three is still underway, which you can tell because the line for it is unfinished. But what happened in these other iterations?
In sprint one, there is a catch-up pattern. The team stalled in its progress from days 8 to 11, and then made a push to finish. As a result, the team signed up for fewer hours in sprint two. This is common, as teams plan for more work than they can get done at first to help them plan for the next sprint.
In sprint two, the team faced a different problem. A bubble of work formed at the beginning because the team didn't plan the sprint process correctly and had to add work.
Both of those issues in the normal rate of work can confuse efforts to forecast the rate of progress based on the first few data points, allowing for improvements down the line. Instead of looking at the trend from the first day's allocated work, for example, take the maximum amount of work anticipated and plot that from day one.
Ideally, the maximum amount of work will be accomplished on the first day. But in the case of "bubble" sprints where work is added mid-course, drawing a line from the sprint's maximum workload as though it were known on day one will give a better presentation of the ideal trend line.
The next problem is a plateau every few days. The graph originally provided data for 14 days including weekends, not just the 10 working days in the sprint. It looks like the team is unproductive every few days, but it is simply a reflection that they took the weekend off. Adjust the burndown chart, as I've done below, by accounting for added work and masking non-workdays and your team will have a clearer picture of its iteration's progress.
What adjustments do you make to burndown charts to ensure an accurate depiction?
Let's look at four types of coaches and how to best utilize them:
Fly in, fly out
This is usually a consultant who comes for a one-time session. He can provide a fresh perspective from having worked with several organizations.
Be sure the session is long enough for the coach to assess the state of your organization. Let his input be uninfluenced by your existing perceptions. Deploy the coach's suggestions in your own way or get him back for more extended consulting. If the coach's observations seem extreme, don't be surprised -- it may be necessary to get to the issues in a short amount of time.
This "contract coach" typically spends a few months advising a team or an individual. This arrangement offers more continuity, as the coach can observe the flow of the process through all stages and still maintain her independent view.
To get the most of your contract coach, be sure to include her in most meetings of the teams being helped. Do not think of these coaches as separate from your team just because they are not regular employees.
Some agile coaches will work alone, as a full-time employee. This situation is advantageous because the coach can set clear direction for an agile team without a potential conflict of interest among his and the proper organizational strategy.
While this arrangement assists in quicker implementation of decisions, it may not allow for as many fresh ideas. It can also be hard to scale the coaching effort to more agile teams as organizational needs grow.
Team of insiders
Some organizations employ an entire team of coaches, which is effective when working with difficult teams because the teams and coaches can support each other. For example, a team may have trouble adopting key practices, but pointers from another coach may help get the team unstuck.
Multiple agile coaches can also balance the workload of coaching multiple teams so no one is overloaded.
The hazard is that the coaches may splinter into competing ideas on how to execute agile. Establish a process for when the gurus do not agree on which agile practices should be emphasized. Strive for a balance of standards and the ability to evolve as new practices emerge from the profession or successful teams.
In general, make sure there is synergy between your agile coaches, tools team, education people, and corporate governance or process definition body.
How do you best work with an agile coach?
See more posts on agile.
See more posts on teams.
Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time.
Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions.
This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning.
Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work).
In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates.
Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less).
This shows how much unplanned work was added during the iteration.
In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints.
What do you think? Have you used these metrics? What metrics do you use to help spot trouble?
Many of today's agile project teams are distributed around the globe. While simple implementations of agile processes assume co-location, in larger enterprises, this is rarely the case. Selecting tools to assist remote communication helps, but it's not enough.
Here are some human factors to consider, beyond the tools, to work successfully with a distributed team:
Cultural differences can become apparent when working with global talent. Some people are uneasy if some social small talk is omitted as part of doing business. Some are uncomfortable if we don't simply get to the point. This affects agile teams as they implement practices such as self-organization, pair programming, and retrospectives. Remember people's assumptions can vary.
Time-zone differences can be helpful by providing longer hours of coverage. But check with your teams on when they begin and end their workday. Different cultures have different laws and traditions on when to go home. Not all people have private transportation, and not all countries use daylight savings time.
Finding teams in compatible time zones can be an advantage with more hours of coverage, if the hours and needs are remembered. Partnering with teams that are north or south of each other makes this easier because the time difference is less extreme.
Communication differences among distributed teams also require forethought. Agile teams will notice a need for engaging and informative tools in their story grooming, estimating, planning and retrospective meetings.
Telephone calls can be awkward because there is no visual cue as to who is speaking and no person to look at. Also, sound varies for each person depending on if they are in the same conference room, on a speakerphone, using a headset or cell phone. Make it a point to include people on the phone if part of the group is face-to-face.
Video conferences or webcams might be a better option. Be aware of the background so it is not distracting. Also be aware of the lighting quality and direction -- illuminating an attendee's face is better than a dark silhouette.
Spatial user interfaces, which extend traditional graphical user Interfaces by using two or three-dimensional renderings, give people someone to look at and allow positional body language and gestures to convey nonverbal information. However, be sure to allow training time for participants so they can make the most of these environments before needing to concentrate on a meeting.
By using the right tool and having the right mindset, agile teams can work together across wide distances.
How do you work successfully with distributed teams?
There is one technique in agile scrum that I particularly like and have found very useful. I'm pretty sure this technique has been around for a long time, only now they have a special name for it: the timeboxed meeting.
Timeboxing is typically used when a project schedule is divided into separate time periods -- each period has its own schedule, deliverables and budget.
When you apply timeboxing to a meeting, each team member answers three questions:
- What was done yesterday?
- What challenges were faced?
- What is the plan for today?
In reality, having team members summarize their last 24 hours into three minutes is challenging. Without focus, and practice, they will undoubtedly fall into the trap of over-elaborating and, worse, finger pointing.
In the beginning, you might want to try five minutes per person, but reduce the number of participants. This means you will have more than one session of timeboxed meetings. As your team gets more comfortable, start reducing the time and adding team members per session.
Remember, the idea is to hold these meetings daily with the objective of sharing updated information quickly. As an added benefit, you're indirectly coaching your team members to be more focused and efficient.
As project managers, we have to determine whether a technique is counterproductive. If the idea of having a daily update meeting seems too taxing, try holding them every other day. If you feel that getting team members together at one time is difficult, improvise and ask them to send text messages or email instead.
Have you used timeboxed meeting techniques? What methods do you use to increase the reporting efficiency within your project team?
The result was The Agile Manifesto, which is comprised of four values and 12 principles.
In August, Laurie Williams, PhD, led the Agile 2011 Conference, where most of those leaders reunited for a panel discussion. Dr. Williams conducted a worldwide, open survey of 335 members of the agile community across the world to research possible changes to the manifesto. She announced her conclusion that the original manifesto remained valid, saying that the original creators of the manifesto "nailed it" -- even 10 years later.
The manifesto authors each talked about the initial meeting held 10 years ago and how agile is trending today.
Bob Martin said, "our original meeting was probably the only meeting in my career that actually worked." Ken Schwaber poured water from a pitcher as a visual metaphor for the last use of waterfall. Jeff Sutherland described how developers he's met in the past 10 years have been moved to tears by having a process that worked.
But the panelists warned that not all teams do agile well. Some teams call themselves agile but don't do the harder practices. The consensus during the panel session was that the moniker of "agile'" will fade away and simply be how we manage projects. Not just for software, but beyond.
The agile conference was impressive because of the growing diversity of tracks. In addition to the usual technical sessions for software testing and development, many sessions covered people skills, including ones on coaching, cultural mapping and distributed teams. Information on the new PMI Agile Certified Practitioner (PMI-ACP)SM certification was also popular.
What will the next 10 years bring? New leadership will expand from the original signatories of the manifesto to those doing agile project management today. And as expressed in the Japanese concept of kaizen, many small improvements will add up to more streamlined productivity in many steps and many teams.
How do you see agile advancing over the years?
Read more about agile.
But when agile meetings focus on logic, numbers or charts, our kinesthetic aptitude may not get used.
Certain agile techniques use body language for visual cues, which exercises this kinetic intelligence. And leveraging it can help engage members of your agile team who don't like to be outspoken.
"Big visible indicators," is an agile term for a technique that often includes a large whiteboard or wall divided into columns. Tasks and stories are moved between the columns as they progress to completion. With a wall covered with colored Post-it® notes, not only is progress more visible, but physically walking up to the board in front of the team to move your item to the completed column makes everyone keenly aware of the progress.
In a recent stand-up meeting, there were a lot of people attending -- many who were just interested observers. As a coach assisting the Scrum Master, I found it hard to know who to call on next. We used a second body language technique, which allowed the observers to sit during the meeting and the participants stood. Suddenly, our meetings went faster.
A third kinesthetic agile technique is "Fist of Five." Team members indicate approval of a plan or decision by holding up anywhere from one to five fingers to vote, five being the most approval.
All of these techniques better engage team members who aren't as comfortable being outspoken on a project team. And as teams become more and more dispersed, recognizing and leveraging kinetic intelligence can lead to stronger agile meetings -- especially if people can use these techniques while seeing their teammates. This can be done with video or other virtual representation technology.
Do you use any of these techniques? If so, which ones? Do they work? What other techniques do you use?
Read more posts on agile.
Read more posts from Bill.
Some commit to their work and complete requirements throughout -- not just at the end.
Other teams struggle. Their sub-tasks may make progress, but their overall requirements or "stories," which express requirements in ways that customers can relate to, seem to get stuck. They finish on the last day of the iteration, if at all.
What makes these teams different?
Often requirements haven't been sub-divided. Queuing theory teaches that the same amount of work divided into smaller pieces flows faster. Teams with stories divided into work durations of one to three days see their work fly through the system. They can finish some requirements and then pick more.
Teams with stories that take a week or more are at risk of a traffic jam. Moreover, we're less aware of the delay until later -- when it's harder to take corrective action.
One correction is to refocus on a smaller number of requirements, but dedicate to finishing those. Another method is to split a story, even though the iteration is underway. Or, remove a story from the current iteration so it can be fully completed in another.
If none of these ideas seem enough, make sure the team is committed. Per the principles in the Agile Manifesto, team members need to self-organize to dedicate themselves to finishing whatever work is planned.
How have you avoided Agile traffic jams in your projects? Has splitting stories to a manageable size helped avoid bottlenecks?
One of the most popular methods of prioritizing Agile project requirements is the "MoSCoW" approach. This stands for 'Must, Should, Could, Won't.' The only problem with this method is that everything is usually a must -- which doesn't allow proper Agile release planning because the requirements aren't necessarily put in order of priority.
Another method is the Kano model, developed by Professor Noriaki Kano, which strives to fulfill requirements and please customers. This model features four components:
• Must haves are elements the product cannot ship without.
• Dissatisfiers are things the product must NOT include.
• Satisfiers include requirements where the more you have the better the product is perceived. Like a marketing checklist, each feature adds incremental value.
• Delighters take the product beyond simply meeting the requirements to boosting customer satisfaction and recommendation.
Several prioritization models put together a table weighted by two variables: features and customers. Each feature is weighted by its value to each customer. The sum of the weights multiplied by the scores makes it possible to see which features are most useful overall across the set of demanding customers.
No matter which technique is used, your list of project requirements must be sorted from most to least valuable.
What techniques do you use to prioritize requirements?
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?
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?
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.
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?
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.
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?
I held my tongue during the formal pitch, but made a point to ask the presenter a few questions after the meeting. Primarily, I wanted to know if he had heard of the triple constraint. The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality.
Some assert that several additional factors come into play when discussing a project's success. I agree with this, but I disagree with removing the triple constraint model from training, as I believe it's such an easy concept to teach, understand and enforce.
My confidence in the triple constraint made it hard for me to believe that anyone had truly convinced themselves they could beat what is, essentially, physics. But sure enough, I got a very firm response from the organization: "We are able to deliver this service because we take an agile approach in our production processes, making us more efficient and thus able to deliver more value for the customer."
Confused, I pressed a little further.
"As I understand it, agile as a methodology does not allow you to overcome the basic physics outlined in the triple constraint. Agile simply prioritizes the tradeoff as one of scope rather than time or quality," I said.
Of course, it wasn't a discussion I was going to win in this setting. Looking around, I saw that the speaker's entire management team had bought into the theory and were smiling proudly at their triumph. I let it go. But it struck me how much confusion still seems to be out there around the triple constraint and the ability of newer methodologies such as agile to overcome it.
How many of you have had your management tell you to explore agile as a way to get your current project work done faster without sacrificing any of the three pillars? And how many of you still use the triple constraint to help you explain the basics physics around project execution?
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.
In John Stenbeck's session, "Agile PM Mastery in 60 Minutes, Guaranteed!" he had a fantastic way of boiling down the essentials and explaining them in a way that traditionally trained project managers easily understand.
Many agile proponents will tell you that the methodology will work within almost any environment that traditional waterfall methodologies will fit. In fact, there's one comment on my previous post suggesting that the issues that I've described -- like needing faster time to market and the ability to address fluid requirement -- would be addressed by implementing agile.
I see a big gap, though: staffing. Agile works best when you have a dedicated team for the life of the project -- or at least the sprint.
But many "consulting-structured" organizations rely on their ability to maximize cost benefits by pooling resources. This means assigning one person to two or more projects at a time. That strikes me as a big issue for an agile team structure.
So, in a non-traditional environment with team members who aren't always dedicated to one project, what are your options in terms of attempting to implement agile?
I look forward to hearing your thoughts.
The adaptive mindset is different than what many people are used to, and different than what some personalities may prefer by nature.
Team members come in with different skills, work styles and views of the world. When teams don't understand this, fights can erupt over simple issues. But when these differences are recognized, the team can leverage the diverse perspectives for better results.
People often view situations through a combination of four basic personalities, according to David Keirsey's temperament sorter:
Artisans prefer to use their skills to adapt to the situation at hand.
Guardians preserve scarce resources and rely on careful planning.
Rationals make decisions based on research data.
Idealists relate well to people's needs and feelings.
These are all legitimate approaches to situations. But strife may occur in teams that don't understand people are born with different inclinations.
What happens, for example, when someone asks a guardian to change a plan? What happens when one asks an artisan to plan too far ahead? Can the facts-based view of the rational inadvertently miss something or trigger some discord? Can an idealist's sensitivity miss a key fact?
All these scenarios are valid, as change, schedule, facts and feelings play out in a business situation. Everyone must realize their teammates may start at a different position when working problems together. Rather than being a source of friction, though, these different positions can be an asset, bringing all the options to light.
Several sessions were particularly notable. Kenny Rubin, Laurie Williams and Mike Cohn shared the Comparative Agility assessment. Using data from 1,600 teams, users can see how their team's agility compares with others.
Ron Jeffries and Chet Hendrickson, famous as original extreme programmer proponents, made a case for a less dogmatic approach to methodologies and suggested using the hybrid best suited to your needs and circumstance.
For me, the most striking part of the conference was the large interest in Kanban, a project management methodology from Japan that emphasizes cycle time instead of utilization of resources. There were seven presentations on it -- all standing room only and overflowing into the halls.
In Kanban, work is purposefully limited so teams are forced to finish items to high quality before moving on. This can yield the same or more output, but reduces the risk that too many half-done items in progress won't get done. Work is tracked on a board with a few simple columns, such as waiting, working and testing done. Each item, or "ticket," is moved from column to column to reflect its state.
Have you ever used Kanban methodology?
Lesson 1: Perform lessons learned sessions during the project.
This lets you benefit from your ideas in time to make a difference.
Lesson 2: Smaller, more frequent meetings flow better.
There aren't as many items to discuss and it becomes easier to focus on observations.
Lesson 3: Don't whine, refine.
Avoid spending a lot of time digging into why problems happened. There won't be enough time to plan for positive changes.
Lesson 4: Follow the cadence of change.
Sometimes we forget the team will be busy with work. Try limiting the changes to two actions. But nail those actions! And don't start new process improvements until the other ideas have been deployed.
Lesson 5: Changes should be by the team, for the team.
Lessons learned should not be viewed as a scorecard -- it will make all the metrics climb to suspiciously good levels. Management should have visibility into the process used and some lessons learned, and anonymous examples of triggers that led to their discovery. But the retrospective itself has to be a judgment-free zone where all problems can be discussed.
If you're using scrum or another agile method, this might sound familiar. Lessons learned or retrospectives are built into your iteration cycle.
How do these tips fit with your project's life cycle model?
The agile methodology of "scrum" is known for its 15-minute daily meetings. Its format contains three questions. Participants state what they did yesterday, what they will to today and what road blocker stands in their way.
The meetings can be deceptively powerful--if used correctly. But oftentimes they drag on for half an hour or more.
So what goes wrong? And how can you get back the benefits? Here are some ideas.
There are two kinds of work covered in a scrum meeting: Specific tasks from your project plans (or iteration backlog), and general interrupts and overhead (such as e-mail and meetings). Do team members ramble on about work that has nothing to do with their iteration backlog? Do they say a lot just to impress other teammates?
Focus the talk on things that relate only to the tasks identified for that particular two-week block of work (an iteration). And then encourage people to focus on and finish two tasks per day. This will discourage the inefficiencies of multitasking. Team members are not limited to calling out roadblocks. They should mention any that appear.
Have you ever heard someone who is "80 percent done" with a task every day? Each new day shows only partial progress, but never completion. Focusing on what was actually finished yesterday, and what will be finished today, helps cure this problem.
The scrum meeting is not about status. It's about completion.
Control the Number of Participants
Let the core testers and developers on the team do the talking. Other people may have an interest in the meeting, but they should just listen.
If your meeting gets bigger than nine people, hold two separate meetings and then have a "scrum of scrums" every few days where representatives from each group get together.
Our inner geek often wants to deep dive into architecture on the fly. (Who can resist?)
In those moments, however, the scrum master (who facilitates the meeting) should say, "That's a great topic, let's set up a time for the two of you to discuss after the meeting."
Don't leave everyone hanging while two people talk. And if you go a week without hearing your scrum master say, "take it offline," there may be room for improvement.
Remember My Three A's:
Awareness: The meeting is about knowing what your teammates are up to.
Ad: The meeting is an advertisement for collaboration. Micro teams of two to three people form, which makes for great collaboration later in the day.
Attack: Attack the blockers. The team can rally to address a problem--either within one minute in the scrum meeting, or more often, after the meeting. Problems that require detailed work by a subset of the team can be arranged for after the meeting. That way, people who are not involved don't have to sit through the discussion.
Those tips will cut the fluff--and speed up your work!
Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance.
Truth: Comparing budgets to actuals is not only useless, it's misleading.
To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement.
Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000.
You time-phase your budget US$1,000 in month one and US$1,000 in month two.
At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing?
If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class.
If you said, "It depends on how many widgets you've made," go to the front of the class.
Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them.
A very simple example, I grant you, but it starkly supports my assertion.
The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry.
Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted.
My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep.
The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be.
What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare.
So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda.
But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary.
So what do you think? Myth or reality?
Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice.
I come to bury agile, not to praise it;
The evil methods do lives after them,
The good is oft interred with their bones,
So let it be with agile.
The noble Waterfall
Hath told you agile was ambitious:
If it were so, it was a grievous fault,
And grievously hath agile answered it.
(Adapted from Julius Caesar, Act 3, Scene 2. You can read Alistair's full monologue here.)
Melodramatic (in a good way) to be sure.
But Alistair, an IT strategist and co-author of the Agile Manifesto, doesn't really believe agile has "met its maker" as the saying goes. Instead, he said agile is in transition--it's not the agile of the 1990s. The landscape has changed. It's grown beyond small organizations and is being applied to much richer, much more complex concepts and projects.
Agile shouldn't be "new news," he said. "We're focusing so heavily on things that are 15 years old, I want to start focusing on things that are current."
He also shared three pillars of 21st century software development:
• Software development is a craft: Developers must pay attention to their skills and to the medium--they must relearn every few years.
• Software development is a cooperative game of invention and communication: It relies on teamwork, communication and strategies.
• Software development should use lean processes: That means small queues, cross-trained people and varied processes.
Hosted by the Agile Alliance, the conference has pulled in 1,400 attendees from more than 38 countries. You can follow all of the conference happenings on Twitter.
Did you attend Alistair's keynote address? What did you think?
More to come.
At the project level, strategic decision-making focuses on optimizing the way the project will be structured and managed. Choosing between using Agile or Waterfall, pre-fabrication or on-site assembly, won't change the required project deliverables but will have a major influence on how the project is delivered and its likely success.
One size does not fit all; simply following previous choices ignores opportunities to enhance the overall probability of the project meeting or exceeding its stakeholders expectations.
Some of the key steps in designing a strategy for success include:
• Familiarization with the overall requirements of the project and its stakeholders
• Determining the key elements of value and success for the project
• Outlining the delivery methodology and getting approval from key stakeholders
• Developing the project's strategic plan based on the available know-how, resources and risk appetite of the stakeholders (including the project management team)
The problem with implementing this critical stage of the overall project delivery lifecycle is that it crosses between the project initiators and the project delivery team. Both parties need to be involved in developing a project delivery strategy that optimizes the opportunity for a successful outcome.
Unfortunately, the opportunities to engage in discussion and planning for project delivery are difficult to arrange. Frequently contract documents effectively prescribe a delivery process, and/or the client and senior management don't know they need to be engaged at this stage of the project lifecycle.
I suggest that project managers and project management offices start focusing more on the project delivery strategy during critical early stages of a project. What has worked or not worked on your projects?
PMI seemed focused on the environment--with a keynote emphasizing the need to be more green--and on the value of project management, with the Research Working Session and a few tracks by PMI personnel on the subject.
The majority of tracks, however, seemed to hit on different topics, including:
1. People issues, like decision-making, leadership, communication, culture, politics and stakeholder management
2. The strategic link of projects, like organizational project management, project selection, portfolio and program management and the PMO
I think this last one is a growing trend in project management.
Many of the concepts of Agile can be traced back to fast-track construction projects, where basic principles like co-location, fast prototyping, iterative development, daily orientation meetings and other concepts were developed.
In IT, the Agile methods evolved in the mid-1990s in reaction to what is called the "waterfall model," a sequential approach to programming.
In 2001, 17 prominent thinkers of what were then called "lightweight methods" issued the Agile Manifesto, which states four basic principles:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Although, in a way, Agile seems to be the antithesis of project management, as explained in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), it can be very advantageous to use it in turbulent and strategic settings.
As project management is used more and more to manage strategic change and projects become more complex, Agile principles will influence more and more the management of projects, and more specifically, program management.
More in my next post ...
While it may not be possible to iterate the building of a piece of machinery, engaging and explaining to the customer in their language--no jargon--what's happening will highlight issues early. If the customer doesn't like something, the sooner you know, the better.
One of the key tenets of Agile is to engage effectively with your customer and end-users, understand their needs and problems, and then deliver an effective solution. This requires regular and effective communication, openness and accountability, and a good measure of trust to support robust relationships between the project team and their key stakeholders. It's a pity so many project managers put their energies into fighting the client rather than collaborating.
Going Light and Lean
Those are hardly new ideas, but they've been embraced by the Agile philosophy for a good reason: They work. Lean was developed by Toyota as a manufacturing philosophy and has been adapted to many other areas. Some of its key principles--such as minimizing unnecessary movement, simplifying process and continuous improvement--have huge potential in project management.
Light is focused on the minimizing unnecessary overhead. Complex plans and processes should be simplified, but only to remove excess complication, not to remove core requirements.
Slimming down the project management overhead to its optimal level is probably the easiest way to free up the resources needed to engage your stakeholders more effectively and is definitely supported by the A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
For more information, see Light Versus Lean -- Steps to Improve Project Efficiency from PMI's Community Post.
By aligning these processes to the Agile delivery methodology, effective project management will enhance the probability of success. But you must recognize the processes are applied differently.
Some of the areas that need an Agile approach include:
Project Scope Management
Traditional project management expects scope management to define the output. The final outputs in an Agile project should be defined in terms of achieved capabilities--how the capability will be achieved will be discovered along the journey.
Change control will be more challenging, as is configuration management. The overall project needs a really good systems architect to keep each iteration or sprint focused on contributing to the big picture.
Project Time Management
In an Agile project, scheduling and workflow become closely aligned. The overall system architecture optimizes the sequence modules needed to be built in to allow progressive testing and implementation of capability.
This defines the schedule. Scheduling should be at a much higher level; each sprint is likely to be a single activity of one to two weeks' duration.
Project Cost Management
Agile projects should be based on either a cost-reimbursable system, or the client accepts scope is a variable based on achieving the maximum improvement possible for a pre-set budget. This is a totally different philosophy to traditional project governance.
Project Quality Management
This is probably easier under Agile. Quality is continually assessed by the involvement of the client and the iterative release of modules to production.
Project Communications Management
The level of trust needed to run an Agile project is much higher than a traditional project. Effective communications in all directions are essential.
Project Procurement Management
Agile works in a collaborative partnering space. In the engineering world these are called alliance contracts. Traditional contracts do not support Agile delivery methods very effectively.
Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful.
Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective?
Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed.
AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective.
The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management.
Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology.
I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ...
Over to you for comment!
The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership.
Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time.
The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt.
An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end."
With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches:
We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value.
We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way.
In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline.
To be continued ...
A letter in the Feedback section of the March PM Network said Agile is not a project management methodology--I agree. Waterfall and various forms of Agile are definitely software development methodologies, not project management methodologies.
However, we can learn a lot with an open dialogue in both directions.
One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.
Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.
Another misconception is that any new software development is automatically a project. Projects are temporary endeavors--this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work.
With these misconceptions cleared, there seem to be three key areas for discussion. (Your comments will be welcome leading into some future blogs.)
What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:
• The need for a much lighter "touch" managing an Agile project
• The need for a higher level of trust in managing Agile teams
• The need for robust change management and configuration management to track the evolution of the Agile project
• The critical importance of developing the correct strategy and architecture at the beginning of the Agile project
Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:
• The need to trust knowledge workers more than manual workers
• Success measured by customer satisfaction rather than quantitative outputs
• The need to keep the client involved
What triggers the choice between operational maintenance and development versus projects and waterfall versus Agile.