By Conrado Morlan
It was a cold and windy morning in Chicago as I lined up among more than 40,000 runners from all over the world. I was ready to start my seventh marathon.
I had set five hours as my target finish time, and I joined a team of runners with the same goal. Before the race at the assigned corral, I met my fellow runners and the pacers who would keep us at the correct speed.
After running the first mile with the group, led by the pacers, I inevitably started to think as a project manager. I realized the race mimics an agile Scrum project, and I began to identify roles and responsibilities based on the context of the race.
The pacers played the Scrum master role. At the end of every mile, they confirmed that the runners’ cadence was right, providing feedback on speed and recommendations on hydration. At the same time, they led the stand-up, checking with every runner on how he or she was doing and if anyone would need additional support. Pacers also kept updating the backlog to ensure product increments were delivered by the runners on every sprint.
The group of runners was the self-managed development team. We had acquired the skills and abilities required to run the race after weeks of training. Our project was set to be completed in eight imaginary sprints of 3.1 miles (5 kilometers) each and would deliver the final product — the ninth sprint. It was our task to keep the cadence and burn rate constant.
As in any project, issues cropped up. On my fifth sprint, I had to make adjustments to my race plan and update my “backlog.” Around mile 15 (kilometer 24), I detected a blood stain on my left foot that kept expanding as I tried to keep my time under 11:30 per mile, so I decided to slow my pace and let the five-hour group go ahead. By mile 19 (kilometer 30), the situation was under control, and I set my new pace. But between mile 24 and 25 (kilometer 40), I had to stop at the aid station for pain reliever ointment to alleviate the discomfort of cramps in my quads.
In any race, no matter the distance, spectators and volunteers are key. They are the stakeholders of the runner’s project. Their function is to provide support along the race with signs, words of encouragement and refreshments. Spectators and volunteers’ commitment to the runners is unconditional.
An important part of the agile approach is the retrospective. For my marathon project, here’s how my retrospective would look:
What went well?
· Enjoyed the experience of running with a pace team
· Finished my seventh consecutive marathon and my first World Major Marathon despite a few problems
· Improved my strength, endurance and recovery time dramatically
What didn’t go so well?
· Not taking advantage of the resources provided at the aid stations
What have I learned?
· Running with a pace team lessens race stress
· The importance of listening to my “brain/body” and paying attention to its signals from the very first step
What still puzzles me?
· After finishing seven consecutive marathons, why do I still want to run more?
· Why do challenges pump adrenaline into project management professionals and runners?
This marathon gave me valuable lessons that will be applied at my next race, the Dallas Marathon, where I look forward to improving my performance.
Do you inevitably start thinking as a project manager when performing non-project related activities? If so, share your experiences.
Cinephiles and regular movie-goers know who Sir Philip Anthony Hopkins is. Sir Anthony is a Welsh actor of film, stage and television, considered to be one of the greatest living actors.
Your journey as a project management practitioner may be similar to Sir Anthony's journey as an actor. You may have to play different roles in projects and might gained recognition for your work. As your journey continues, you may be looking for the next stop that may lead you to explore other project management disciplines, like agile -- and, in particular, the role of an agile scrum master.
From Stage to Movie Set
Versatility is a virtue of all great actors. Though Sir Anthony has experience as a stage actor, acting for a film is quite different. As a stage actor, Sir Anthony had to undergo many rehearsal hours, and experienced a specific, tight-knit team of actors and staff. Lighting and environment are essential for the performance and there is no room for error in every live show. A theatrical play delivers a well-defined "product" that may resemble what agilists call a "traditional project" under waterfall methodology. As a project manager, you "manage the stage" of the project, meeting the stakeholders' pre-defined requirements and applying your skills supported by the project team. Your project will deliver the product or service it was intended for.
But on the film set, Sir Anthony likely needed to be more flexible, since a scene may require several takes until the director is pleased. The film set is more dynamic: different locations; a different type of crew; the addition or removal of stunts, etc. The phases of a motion picture-making -- pre-production, principal cinematography and post-production -- are similar to sprints in an agile environment.
Sir Anthony makes transferring acting skills from stage to the film set seem easy. But like him, you also have transferrable skills: you can communicate, influence, orchestrate and remove roadblocks. You can use these talents to help you adjust to the new project environment.
From Hannibal to Odin
While Sir Anthony has occupied diverse roles -- from Richard Nixon (Nixon, 1995) to Odin (Thor, 2011) -- he's been successful because he's always prepared properly, trained to correctly represent the character and depended on his foundation as an actor (whatever the media).
As a project practitioner, you are likely familiar with PMI's A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fifth Edition, tools and techniques; best practices; and project methodology of the company or customer you work for. Those elements complement your preparation and training as a project manager -- and lay the foundation to explore and learn new methodologies like agile.
What is your experience as a project management practitioner transitioning to scrum master?
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.