Scrumming in the classroom
Winter Session course in IT Project Management plays a valuable game
11:52 a.m., Jan. 28, 2014--The loud “pop” of overinflated balloons disrupted the steady hum of communication in the classroom. Blue, green, orange; successfully inflated ones drifted from desk to desk.
Students in Barbara Cullis' Project Management and Costing Winter Session class weren't hosting a carnival. Rather, they were learning scrum, an agile method of software project development, and they were being led by a team of developers from JPMorgan Chase.
Board of Trustees
Lifelong learning registration, open houses
“It really shows the strong spirit of collaboration between the two organizations,” Cullis, a supplemental instructor in the University of Delaware's Department of Accounting and MIS, said of JPMorgan Chase's participation. She reached out to the company and it arrived with a team of seven to help her students learn.
Marion Morgenthal, vice president of technology organizational change and development for JPMorgan Chase, said the company really wanted to provide the class with a hands-on experience, just as JPMorgan Chase does with teams of engineers in its Expert Engineer (E2) program.
Agile is a strategy for developing deliverables to users in a dynamic way, with the highest business value in the shortest amount of time. In scrum - just as in rugby, from which the term has been co-opted – members of a software development team come together at iterative stages to move forward as one.
In Cullis' graduate Winter Session class, teams of students had already been working together twice a week to engage in case work and to build a software development proposal. The focus of the course is on the creation of organizational value through the application of project management best practices.
Last Thursday night, JPMorgan Chase was on-hand to teach the class not only agile and scrum but also about extreme programming and how agile is used in enterprise.
To start, they played a “game” that taught them how agile works.
“Your job is to make your customer happy,” said Morgenthal, as she assigned each team a JPMorgan Chase “coach” for the game.
Coaches, like James White, an applications developer with JPMorgan Chase Central Technology, handed out a stack of cards that contained “stories,” essentially the deliverables the team of “developers” -- the students -- would strive to implement.
The stories ranged from folding 10 paper hats, to building a four-story house of cards and inflating 10 balloons to a particular circumference.
For the first iteration of the game, the teams were given a basic set of instructions: Determine which story is the simplest and assign it a value of two; determine how long it would take to complete it; assign all other stories a complexity value relative to the time it would take to complete the simplest task.
Then, they assumed the role of the “customer” and decided which stories they wanted to complete, in order of priority, within a three-minute window.
“As a developer, you've already organized your level of effort,” White told his team. “Now, as a customer, pick as many things as you think you can fit in three minutes.”
The students examined the stories and discussed which ones they thought they could achieve based on estimates of how long it would take to complete each.
“I say we do these four, definitely,” said Allen Orr, a graduate student member of the team, pointing to story cards laid across the table.
Another member of the team, Yu Zhu, was pushing to complete a seemingly time-intensive task with a business value of 500. The team decided to save it for the end, just in case. The team chose a stack of stories worth a total of 19 complexity points, each of varying business value.
Then, the team switched back to developers and got to work on each one. They were allowed to work on only one story at a time and White, now the customer, had to approve each product before the team moved on to the next story.
Cullis, a former Scrum Master, walked around the room, amused by the flurry of activity while the students stacked, folded and inflated.
“Who thought they came to graduate school to fold paper hats,” she said, smiling, clearly pleased by the hands-on activity in which her students took part.
At the end of the first story – the team chose to fold 10 sheets of blue and gold paper into hatsv – White evaluated the product. It took the team just over 30 seconds, or twice as long as it had imagined, to complete it.
“This one's kind of broken,” White said, placing the paper hat aside. “This one's uneven … I don't think I can take these, they're not what I need.”
To their dismay, the developer team learned the customer was not happy with what it created. That's when team member Jon Cuprak spoke up.
“What do you want?” he asked White, curious how the team could deliver what White wanted. He posed a question the team had not previously thought to ask.
That's when the tide began to turn and the team began to realize the lessons of agile. In its second go around, the second iteration, the team asked White what he wanted from each story before it chose. It made prototypes to learn how long it would really take to complete each one and how complex or simple each truly would be.
“Whether you are successful or not depends on the value you provide,” Morgenthal told the students. “Ask your user; don't assume. Find out as much as you can what the expectations are and get as much information up front as you can get.”
In the first iteration, White's team earned four of its expected 19 complexity points, with a cumulative total of 300 business value points. It carried those four points, the “velocity,” into the next iteration.
With each iteration, teams had to match or build upon their velocity. Otherwise, their value dropped. Teams needed to choose their stories carefully each time.
By the end of the second iteration, White's team was tied for value with another team headed by JPMorgan Chase's Bupendra Singh, vice president in Global Wealth Management Technology. However, Singh's team had a much higher velocity to achieve in future iterations.
After each iteration, teams came together in a scrum, reviewing what they had done and the lessons they had learned. They worked out plans for the next step.
This is exactly the idea behind scrum and agile. Each successive iteration allows the developer to improve and to rapidly and dynamically respond to the needs of the user.
“I think they asked a lot of questions,” Singh said about his team after their success in the second iteration.
“Lot's of pre-planning helped,” said Cuprak, of his team's efforts in the second iteration. This was a more successful attempt for his team.
By the end, Cullis felt the event equipped the students with new skills they can apply in the workplace, increasing the successful delivery and value creation of their IT projects.
For Morgenthal, the fun was in watching the evolution of agile learning, as students moved through the iterations and refined their process.
“It's fascinating how much faster their estimation goes and they really learn a lot in a short amount of time,” she said.
Article by Kelly April Tyrrell
Photos by Evan Krape