Viewing Posts by William Krebs
As agile matures, it's being employed at the program level by larger teams, many of which are broken down into groups. How must agile evolve to match these growing needs? In this first of two posts, we will look at some of the key objectives of the agile approaches designed for large-scale projects.
Scott Ambler's Disciplined Agile Delivery and Dean Leffingwell's Scaled Agile Framework are two such approaches. These in particular reevaluate some concepts from the IBM Rational Unified Process framework. Among the most useful concepts shared by all three is the opportunity for teams to balance upfront planning needs while preserving agile's ability to refine the plan based on empirical observation of real results. All also speak more to what architectural underpinnings are necessary to give larger teams a firm foundation:
In larger teams, agile approaches -- such as the feedback afforded by iterations in Scrum -- remain popular, as do the technical practices centered around quality. Lean principles used by smaller agile teams remain important to reduce wait time, optimize the entire system and balance flow among teams. But the frameworks mentioned above also add a fourth dimension: synchronized relationships among agile teams. In particular, aligning teams so their sprints end at the same time is useful, because it facilitates the release of the product.
So what's different for large teams trying to use agile methods? First, overall investment governance becomes all the more important. Larger projects require more preparation to justify the greater levels of funding. They also may have more complicated dependencies among teams. Organizations will need to find a way to allocate effort between work in their portfolio of projects. This includes not only features, but also infrastructure work and nonfunctional requirements. And organizations should also use investment gate models to ensure funds are invested wisely.
Second, technical architecture is also very important. In smaller agile teams, people may experiment first and then evolve guidelines and patterns. But in larger teams, overall design and architecture plays a leading role so as to better coordinate among teams. System teams, or people who work on supporting teams creating features, also become important as the demand for a shared infrastructure increases.
Finally, metrics quickly become important. New metrics -- designed specifically for larger teams -- provide a holistic view of the overall health of the large team, and also help gather and assemble data for the smaller groups within. This allows organizational leaders to see, at a glance, where the overall program stands, so they can make broad project decisions with wide impact.
These general principles guide many methods to scale agile from teams of seven to 100 members. In my next post, we will look at some specific practices to enable large teams to find the benefits of agile.
What do you think are the fundamental principles of scaling agile?
When we're first introduced to agile, we learn so many steps and procedures that it's easy to forget why they're useful. The exam to become a PMI Agile Certified Practitioner (PMI-ACP)® asks questions on practices -- and it also does a good job of testing your knowledge of the value behind them.
Yet knowing the "why" behind a practice helps you keep close to the core values of agile when handling unforeseen situations.
1. We graph, but why? The concepts of big visible indicators or information radiators deliver two benefits: a self-organized team and risk reduction. Graphing helps the team react more quickly, since everyone sees the same data at once, rather than one leader looking at the data and then issuing decisions.
When graphs illustrate the risk of falling behind, the team is able to take action. Whether you are using Scrum or Extreme Programming (XP), visible charts are crucial to understanding your rate of work. Remember that completing charts is as important as knowing how to interpret the message they present.
2. We have a task board, but why? A task board shows a list of work in at least three columns: "To Do," "In Progress" and "Done." Some teams have paper notes, or the electronic equivalent, that march across the board as work progresses. But not every team asks the all-important question: "Are we juggling too much at the same time?"
Visual task boards make it easier to see when things start falling behind. Don't just watch the tasks move across the task board. If a traffic jam develops in the middle of the board, ask why.
For example, lean and Kanban methods visually highlight the need to limit the work "in progress," or how many tasks your team is juggling. You can do the same amount of work, but focus and finish a few at a time. This improves your cycle time and surfaces any risks earlier.
3. We have a process coach, but why? In both Scrum and XP, there is a role on the team tasked with knowing the process and making it perform as advertised. In the case of Scrum, that is the Scrum master's job. In the case of XP, it's the coach's job.
Process coaches are instrumental in fostering your team's ability to self-organize rather than relying on one leader to delegate work. If you have a coach on your team spending more time assigning work than mentoring others to use a process, then your team's ability to self-organize -- and foster nimble work and cross-functional roles -- suffers.
4. We communicate openly, but why is this important? It's easy to avoid conflict and let disagreements stand, but agile relies on surfacing issues so they can be dealt with as early as possible. The social contract of the agile team must be "Bad news is good" and "We're all in it together."
The only bad issue is one that doesn't get raised. If you communicate but don't mention controversial points, then you're veering from agile values -- and perhaps growing less agile for it.
What other agile values are important to you and your teams?
Distributed agile teams have to overcome distance and time to achieve what Alistair Cockburn describes as "osmotic communication" -- tacit knowledge and spontaneous discussion. Speakers at an October 2012 summit on distributed agile teams offered six tips for improving high-bandwidth communication:
1. Make a Time Zone Table. You may know this already, but this tool is a must for finding times for meetings required by your agile process, including daily Scrum meetings, estimating, planning, demos and retrospectives. To create one, use a spreadsheet to list rows of times for potential meetings and corresponding time zones for all members. For example:
Be aware of each location's typical work hours, and make a separate table or calendar of holidays.
2. Break language barriers. Even when remote team members speak the same language, don't assume smooth communications. For example, some people have heavier accents than others. Language barriers can particularly impact the efficiency of agile teams, which include daily standup meetings. One solution is to assign a spokesperson with better language skills in the team's common language (English, for example). Also, be mindful of cultural metaphors and idioms that may not make sense in other countries.
3. Increase visibility. Because agile teams use task boards to show stories and associated work, communications can become complicated for distributed teams. To show the many visual elements used in agile -- from notecards on a wall to task boards -- teams need to think beyond web cameras. Try using online tools, which can range from free task boards to full-service applications with analytics and portfolio management. Or opt for spatial collaboration environments such as TerfÂ©. Terf shows cards for each task on the wall in the context of other charts and team members. Online virtual rooms deliver contextual information and a sense of co-presence, where distributed agile teams experience the collaboration they are accustomed to in a face-to-face environment.
4. Improve sound. Agile teams rely on high-bandwidth communication. And clear audio is essential in the frequent meetings necessary in the agile process. So if you are using voiceover IP, avoid wireless for a more stable connection. Little things go a long way in improving sound quality, too. Use a USB headset or ear buds to avoid feedback and echoes from built-in speakers. Consider investing in a better microphone. Some have digital signal processing to reduce noise, some are excellent for large rooms and some have different patterns to accept or reject sound. Finally, provide text chat for backup communication and questions during a long discussion.
5. Go on the record. Recording audio from conference calls and screens from slide presentations keep team members informed if they cannot attend in real time. This is especially helpful for informing offshore team members in crucial content meetings, such as agile planning. Just beware that without the interactivity, it is harder for people to remain engaged. So with recordings, try to keep it short.
6. Organize by component, not role. Some teams may be tempted to assign people in one location one role. Yet team members on agile teams are encouraged to share roles. So what's the solution? Cross-functional teams by location, working on a subset of your project. This improves communication between locals, reducing overhead.
What communication challenges and solutions have you experienced for your distributed teams?
Go beyond communication tips -- find out how to apply measures and metrics of agile techniques into your projects. PMI members can dig deeper into the topic, with expert tips on the many facets of agile.
Using an agile approach allows project managers to spot right away when things are falling behind.
1. Different levels of planning. Agile gives us the best of both worlds: a broad strategic picture and a real-time focused view.
In Scrum, for example, teams plan at three levels: release, sprint and daily commitments. The release plans are designed to be risk tolerant and prevent teams from missing strategic goals because you can change 'in-flight' during the product release. The sprint plan pauses the changes so teams can focus for two weeks.
At the daily stand-up meeting, individuals commit to their team members to finish something that day, which helps people collaborate when needed.
2. Blocker busting. One of U.S. statistician W. Edwards Deming's 14 principles for management is "remove barriers." Agile implements this at the daily stand-up meeting, where team members are encouraged to voice any blocker impending the project so that the team can assist in eliminating it.
3. Visibility. Agile uses tools like the release burn-down and sprint burn-down charts, as well as the task board to immediately show trouble in projects. Having them, using them and taking action when they highlight problems results in getting the most benefit.
4. Story flexibility. The waterfall approach assumes that all requirements can be explicitly defined at the start. Care is taken to create a solid plan and then control scope. In agile, it's an iterative and incremental approach. We admit pressure for scope changes will occur.
Agile builds the ability to deal with change into its approach. A story, which is a means to show current and new project requirements, can be added during the release between sprints, and stories that are likely to suffer quality problems can be dropped from a sprint or release.
5. Empirical planning adjustment. Agile plans look at previous results with the current team and environment to better estimate how much work to do in the future. Every sprint and release teaches the team more about how much it should plan for future iterations.
6. Retrospective actions. Agile has a built-in step to openly discuss the difficult parts of the team's process and focus on actions to improve in the future. Rather than wait until the end of the project when it's too late to improve the outcome, agile features 'retrospectives' or 'lessons learned' at the end of each iteration.These meetings review what went well, what went wrong, and how to improve for the next iteration.
Given these six opportunities to spot problems during all stages of the project, it's unlikely trouble will escape undetected for long.
How else do you think agile helps keep projects on track?
| The agile process helps reduce such risks as poor product quality or building the wrong product entirely. Though agile and Scrum were originally designed for software projects, their iterative process and techniques apply beyond their initial intended industry.|
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:
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.