9
$\begingroup$

I am planning to teach an undergraduate-level course on mobile application development. I have been thinking about the best way to structure such a course, and am starting to believe that an agile approach might have merit.

The idea is:

  • Start the semester with a fully populated product backlog that lists all the components of the curriculum.
    • This means user story statements, detailed descriptions, story point values, and acceptance criteria are all detailed.
  • At the beginning of each week's session,
    • get the product owners (the students) to choose the topics for the coming week's lectures and assessment.
    • do a retrospective on the previous week's outcomes.
  • Periodically, replan and reschedule the curriculum (backlog).

The students are seniors or juniors and one deliverable for the course is that, by the end, they have written a mobile application that makes use of web services, location services, graphical information display, and a mobile database.

Also, the students should be able to use version control, do an appropriate amount of software and UI/UX design, perform reviews of others' code, incorporate automated and manual testing into their projects.

Because they are nearing the end of their studies, I believe showing them how a "real world" agile project might work in the scope of what they currently do (studying) would be a good secondary goal.

My questions are:

  • What are the downsides to this approach for the students? For me?
  • Does anyone have any resources referencing others who have taken this approach?

Update

Sprints

So it looks like, based on the school calendar, that we'll have enough time for an introductory session, four three-week sprints, a final demo session and two floating sessions available or other work.

What is the Product?

So there are two approaches to this:

  • Assume the "product" is student knowledge about mobile application development and have each student select items from the generic backlog to work on each sprint.

  • Assume the "product" is a mobile app that must meet certain criteria in terms of functionality and have each student define their app, which will then produce user stories.

Product: Student Knowledge

This can be seen as subvert[ing] the very purpose and essence of agile development, as Buffy noted.

If done properly, this might not be the case: the aim is to fill in each student's knowledge gaps. That will need to be highly adaptive per student and, probably, per topic area.

If I'm the product owner then I get to say whether they've met the acceptance criteria --- they know enough about the topic of the user story.

If, instead, we get another student to be the product owner (or perhaps "QA" with delegation from me as PO), then the idea of pairing can be brought in as the student will have to come to some mutual understanding of the "definition of done".

Acceptance Criteria

Examples of User Stories

Product: Mobile App

If the product is the mobile application, then this simplifies things and makes the agile approach closer to what a software engineer would have to follow in a real work environment.

Here, if I'm the product owner, then I'll need to understand all the possible apps (if the students get to choose their own app idea).

Again, it might be better for that to be delegated to another student or group of students.

Acceptance Criteria

Examples of User Stories

$\endgroup$
  • 3
    $\begingroup$ Welcome to the site. And nice question. The idea filled me with excitement. I would love to hear how it went, after you have done it. Please at this time add an answer as a retrospective. $\endgroup$ – ctrl-alt-delor Nov 29 '17 at 17:16
  • $\begingroup$ @ctrl-alt-delor Thank-you for your kind words. I'll certainly do that! $\endgroup$ – Peter K. Nov 29 '17 at 17:28
  • 1
    $\begingroup$ Actually, the developer role and the product owner role should be separated. The product owner could be one or two students or yourself, but not the class. I assume you are providing the backlog. I can provide some guidance, but your bullet points as stated confuse me a bit. But what you want is feasible, certainly. $\endgroup$ – Buffy Nov 29 '17 at 17:38
  • $\begingroup$ @Buffy Yes, having a small group of product owners might be better than the whole class. However, having some class input is, I think, essential. $\endgroup$ – Peter K. Nov 29 '17 at 17:53
  • 1
    $\begingroup$ I just finished the Android course for my BAS in Software Development, and I'd be worried about time and schedule and covering enough of the basics right at the start so that the students can actually do something (setting up Android Studio, getting the emulator set up for whatever target you spec,etc) and then learning the app/activity lifecycle and fragment management and such. I do like the idea of incorporating agile/scrum though - you could use it for the second half of the course for students to complete a final project. $\endgroup$ – ivanivan Dec 5 '17 at 5:36
4
$\begingroup$

Don't subvert the very purpose and essence of agile development: the ability of the product owner to re-target the project (almost) instantly and make changes and adjustments to the backlog as business conditions dictate. The alternative of specifying everything at the start has failed repeatedly in long running projects in which it makes no sense whatever to follow the initial plan.

Some of what I write below assumes you (or a future reader) is familiar with the terminology and the purpose of the various roles and tasks. To try to be complete would require a text-book.

So....

You need to separate the developer group (Devs) from the product owner (PO) (person or group). I normally do this randomly, but other things might work. The PO has control of the backlog and releases features from it per iteration. The developers don't see the whole thing other than in overview form at the start. If you don't want the Devs to do estimation you aren't doing agile, so they should do that, per iteration for the most currently relevant cards (features). Then they give the PO a "velocity" that will determine how many features can be in the iteration. If you are doing a project in one term, iterations should be short (1 week?) and small. But even if they don't estimate time per task, having been pre-determined, then they should still give velocity, having seen a few of the features desired now. Otherwise they will just be frustrated by too much work in too little time. That leads to burnout and is not agile.

The downside is that the PO doesn't get to develop. That may be an advantage depending on the makeup of your student group, or not. I prefer to be the PO myself so that I can throw in a kink or two along the way.

As ctrl-alt-delor says, you need to prevent speculative, build-ahead, development. You have to be fierce in rejecting all attempts at it. Not showing the entire backlog helps with this, but simply rejecting any feature produced speculatively is needed. The problem is that your students have likely gotten in to one bad habit. They have probably in the past been given partly specified projects and assignments where "creativity" is valued. So they try to get creative, by their own definition, ignoring the needs of the PO. In the real world it seldom works that way (Startups excepted) and you need to learn to work to someone else's vision not your own. So you need to make that work in the class.

The following is speculative and I haven't tried it. If you really want every student to experience every role then do this: Appoint a PO somehow for the first iteration and they hold that role throughout. Accepting or rejecting (with your guidance) backlog items as they are "completed." Then at the end of the iteration rotate roles so that the old PO becomes a developer and some other student takes on the PO role. They will need some time to become familiar with the backlog, however, so it probably can't happen that the iteration ends one day and a new PO takes over and specifies the next iteration immediately. A negative aspect of this is that the old PO will have knowledge they shouldn't have (and wouldn't have) in reality which may make them eager to speculate.

I would also require the "small-ball" skills (sorry, US baseball term) that Extreme Programming suggests. I.e. personal skills: pairing, test first, etc. Pairing will help them teach one another and build team skills.

Another possibility for doing a course on Agile Development, though it doesn't match your stated requirements is as follows. (I say this as others may benefit). Instead of one large project have a bunch of tiny projects with 10 minute features and 30 minute iterations. If you run a course in 3 hour segments this can be made to work. In fact, I know of one real-world outfit that does this sort of thing on real (i.e. large) projects - maybe one hour iterations. With such a scheme a person is PO for one project but will take a different role the next day.

At some point in any agile course, trying to be realistic, you need to throw a curve-ball (sorry). Change the backlog/project-direction in some fundamental way. Estimate from the current code-base and move on as usual. It really happens that way (experience here) and also shows that the word "agile" actually means something. Trying to make the initial requirements too precise is also a problem/trap that will encourage speculation. Real agile projects don't work that way. The initial backlog is pretty vague about specifications. It is only as you approach the iteration in which a feature appears that it becomes specific.

You will need to guide the PO so that they do sensible things. You will probably need to be the project Coach. If you need to ease the development you could provide some of the tests (unit tests) to guide the developers. After doing this initially they can take over. But you need to give them advice (as coach) on the quality of their tests.

Note that I've merged ideas from both Scrum and XP here. Scrum works well for the overall management (Backlogs, acceptance...) and XP for the day to day tasks (pairing, testing...). If you don't require day-to-day level skills the students will probably just thrash. Agile requires discipline, which is often missed - especially by those who reject it.

There is more to say, of course. But the bottom line is that to teach agile you need to be agile.

$\endgroup$
  • $\begingroup$ Wow, that's a lot to digest! Thank-you! I will say that what I want to teach in the course will not fit into one semester, so in that sense we'll have to be agile: what is taught will be determined by the product owner group. I'll respond more as I consider your answer. $\endgroup$ – Peter K. Nov 29 '17 at 19:29
  • $\begingroup$ You don't need to give up. You can be agile in a smaller project as well as a big one. If you choose features wisely you can also have a "useful" part of a bigger project done in a term. An agile project is "done" when its PO says it is done, not when the backlog is gone. Build features in order of value (which then decreases as you go). Quit when the cost of the next set of features exceeds the value. Costs rise per feature since they are integrated into an increasingly complex application. $\endgroup$ – Buffy Nov 29 '17 at 19:58
4
$\begingroup$

The biggest issue I see is that you are taking your curriculum and trying to approach it using SCRUM terms. The result is a lot of "almost SCRUM" behaviors which could be tremendously damaging. I've seen many SCRUM teams fail because a Product Owner or Scrum Master forced "almost SCRUM" mentalities on the team.

Instead of taking your curriculum and trying to approach it with SCRUM terms, I recommend starting with the SCRUM process, and trying to apply it to your curriculum. The reason I think this will work better is because SCRUM is designed to produce a product, such as the learning of your curriculum. Your curriculum is not necessarily designed to operate in SCRUM. Let SCRUM take charge, and do what it's good at.

One key aspect of this application is that you are going to wear three hats: Product Owner, Scrum Master, and Manager. Manager is not actually a SCRUM role, but it is essential for stability. If a real life SCRUM team refuses to build sprints which support the Product Owner sufficiently, That PO will have a talk with the functional management of the team and everyone will be receiving bad performance reviews for the year. The school-house equivalent for that is being given a bad grade. Thus, "support of the SCRUM process" should be a line item in your grades for the students. Maybe you tell the students that the first 10-20% of their grade is "free" unless they disrupt the SCRUM process enough to force you (as the PO) to have a talk with yourself (as the manager). If you coach it right, they'll think of it as a free A on a test or something like that.

With that ugly manager hat out of the way, we can look at the other ones. Product Owner will be the most interesting. Like an industry PO, you have an obligation to produce a product for your customer: your administration and these children's parents expect learning. Explain to the students that, when you're wearing the PO hat, your job is to deliver the curriculum to the expectations of these customers.

I would expect two major styles of behavior here. If the students are on-pace with the curriculum, the PO should operate like any real-life product owner would: egging the team on to produce more product faster, and maybe giving them more freedom to craft the backlog the way they want to see it. However, if the students are falling behind (i.e. the PO may not be able to deliver the "learning" to the customer), and the students aren't ameliorating this in their sprints, the PO should start tightening the reins offering less agility, and instead picking sure-fire ways to cover the material (which are probably more boring), and you will be talking with yourself (as Manager) about those SCRUM grades. The students should understand this up front. If they start to fall behind, there should be a desire on their part to resolve the issue before the PO comes in and takes away their freedoms. It should be easy enough for them to understand, but knowing how the game works up-front is key.

Then there's the Scrum Master. The SM is known as the "servant-leader" of the team. They are there to facilitate the team in any way needed to make the SCRUM team successful. Note how different that job description is from the PO. You are going to need to make it very clear when you are acting as SM and when you are acting as PO. This might actually involve funny headgear, or it might just involve some metacommunicating to tell people who you are acting as.

As an example, let's recognize that this SCRUM effort is an experiment. It might not actually fit well into the school model. What happens if it's a bad match? The first thing that you'll notice is that you (as PO), start to get unhappy because you're not delivering "learning" on-time. You're falling behind schedule. The PO is then going to push on the team to produce more. As SM, you then need to work with them to try to plan better sprints to meet the PO's needs. Now in this case, we're looking at the case where this fails. Now the PO is extremely unhappy and is ready to talk to the Manager about how bad the team is performing (and take away their SCRUM support grade). At this point, you might need to do some metacommunication to recover:

So I wanted to try to run this class in a SCRUM setting. As you've seen from my emails to you guys as Product Owner, I'm not happy with the results. Your SCRUM effort is simply not working.

At this point, a real Product Owner and a real Scrum Master would sit down and talk about what's going on. They'd try to identify the root cause. So as Scrum Master, the servant-leader of the group, I'd come to the table arguing that the team is actually doing their job, the task was just too big.

At this point in the semester, I, as Product Owner, agree with the Scrum Master. You guys have done your job making SCRUM work as best as it could. The curriculum just doesn't fit. So as Product Owner, I'm deciding to terminate the SCRUM and go back to a traditional teaching approach. Since its clear you guys did your job for making it work, I'm not going to the Manager to try to ding you guys for your performance. You did great. You all get the 20% SCRUM support points. But instead of it being part of scrum, it's just going to be like it was a Test. It's like a test you didn't have to study for, and you all got A's. Congratulations.

Now back to your regularly scheduled classroom.

Can you see how murky that would be if you blurred the 3 hats? It needs to be clear that, in this process, you will have at least 1 person in your corner: your Scrum Master. If they can't see that, they may rebel against the idea.

Now sprint planning will be the last major challenge I think. There's a few issues here. One is that you have too many people on the team. SCRUM teams work best in small numbers. A classroom is likely too many. You will probably have to adapt the sprint planning process to fit reality.

The other challenge in planning is that your students aren't the experts here. You are. They don't really know enough to break down the backlog items into tasks that can fit into the sprint. As a result, you may have to help. As part of the Product Backlog, you may want to provide suggestions for how to approach each curriculum item (such as "Lecture" and "Problem set A" and "Problem set B" and "Research"), along with some way of estimating how long the task should take. Let them assign the story points -- it's an essential learning process for SCRUM. If they want to try to learn the curriculum in a different way from what you provided, then you may need to introduce the concept of the Sprint Goal, and explain how they can use that to provide cohesion.

Also, do remember flexibility. As a PO, you are going to have to demonstrate to your customers that these students learned the material. That's all. If you can work with them to find clever ways to demonstrate that they are learning what they need to learn, then always let them deviate from the obvious curriculum. If you're teaching sockets, do you really need the backlog item "Learn to use select()?" Or can we add a new item "use asynchronous threads to add functionality to the awesome product produced last sprint?" The answer really depends on how much freedom you have in your curriculum.

$\endgroup$
  • $\begingroup$ A key idea here is that you can make the student's successful even if your course design fails and the project fails as well. Students can learn as much from this as from success. Good job. +1. $\endgroup$ – Buffy Nov 30 '17 at 11:34
  • $\begingroup$ More great feedback! Thank-you! I did think about how to distinguish the roles : especially for people new to it, it could be very confusing who is doing what, when, and why they are doing it. All three answers so far have giving me lots to mull over. I will try to edit my question on the weekend to update it with more details trying to address all your concerns. $\endgroup$ – Peter K. Nov 30 '17 at 12:45
2
$\begingroup$

I fear A Rushing ahead

The main problem will probably be.

Some pupils will see the product backlog, and start working on it ahead of time (This is good so far), but they will probably work on it all at the same time (AHHH).

Therefore do not release all of the backlog at the start. Insure that you teach “«Work In Progress» is bad, so keep it to a minimum” before releasing it all.

No Regrets

There may be learning dependencies, that means that some items can not be delivered early. If pupils where to chose them, then there would be a problem.

Therefore carefully choose the initial set for the backlog, so that it contains items that are suitable at the early stage. But later these dependencies can be considered by the students (you could mark the invisible ones on the backlog so they are aware).

Shot Through The Heart, And You're To Blame.

You could Give agile A Bad Name.

Ensure that you know Agile well. I have worked with many developers, than say “Agile does not work, I have tried it.” They have not tried it, but someone had heard that Agile was good, so relabelled some bad practice, Or did not learn it properly and made something up.

$\endgroup$
  • $\begingroup$ Great feedback! Thank-you. I've worked as part of an agile team for the last ~10 years, and have taught it under the SW project management label so I believe I am well-versed in its details. I'll have to see how to keep the full scope "hidden" or "partially revealed" (tool-wise, I mean). $\endgroup$ – Peter K. Nov 29 '17 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.