Students – 3 lessons to help operationalise the theory of the classroom

by | Aug 4, 2015

Our awesome team of WelTec Bachelor of Information Technology students have been with us a few weeks now and it would be fair to say their learning curve has been steeper than any of us envisaged. Emersion into our office life has commenced well with daily standups, cake eating opportunities (they bake, we buy), technical onboarding for tools and techniques and go-to people have all helped with that dimension of the journey so far.
One of my goals for entering into this project was to understand, document and share an accessible approach for companies large and small to bring students into their environment as a means of investing in the future of our industry. The insight we – both OptimalBI and the student team – will gain should provide fabulous lessons and practical methods for productive, engaged, blended teams.
It is fair to say that this team have been exposed to a wealth of theory in their studies, without the benefit of opportunity to put that theory into practice. Steep learning curve and pressure to deliver should really help them operationalise what they have learned. Eyes open here though, we will all learn a few lessons as we go – here are three of them so far:

Assume nothing

Lesson #1 for the OptimalBI team has been not everyone has the same experienced based understanding.  It’s like driving for the first time, you might have watched your parents drive for years have read the road code and watched the video’s – all of this is theory until you actually sit in that seat yourself.  We assumed the nods of “yes we have learned agile” meant a common understanding, what it did mean (which is very positive) is the language was common, experiencing that language was not.
Another surprising example has been working as a team, sharing the backlog and leveraging each other’s skills aren’t natural behaviour when you have been a student working as an individual for 3 years – creating opportunities to collaborate and providing guidance on how to construct acceptance criteria geared towards collaboration and sharing it transpires is an important support mechanism.
Working as a team goes beyond co-location or common work product. There are skills and techniques we develop throughout our careers like respecting our colleagues capabilities, being supportive helping them to learn and grow, not putting up roadblocks for the sake of them or lobbing grenades to highlight I-know-more-than-you-know (not saying these things have happened, these are examples I have experienced over the years). Working as a team is hard and it’s easy to revert back to teams of 1, plus it’s easy to assume everyone knows how to work as a team.
Give a team tools, techniques and time to form and establish their norm, then you will see the real productivity benefits.

Plan first, then do 

This adage is perfect – measure twice, cut once – in an Agile path you plan twice and build once, planning at a high level up front and then at a detailed level every sprint (actually you plan many times with backlog grooming to a certain degree assists forming the larger plan in our mind).
The Scope / Plan phase of our productisation process – usually Sprint 0 – at a high level is a mechanism for informing the ongoing iterations of design, build, test, deploy, document and support throughout the project. It takes us through visioning, customer journey mapping, customer persona definition, describing Epics for the product backlog, high level product roadmap (long before eliciting the detailed one) and other steps which all culminate in a Product Establishment Document.
One technique we like to employ at OptimalBI is research stories, this construct has changed our natural behaviour of – go off and spend time “researching” a thing by structuring that research objective into a story format. Research stories are written from a customer persona perspective to provide focus and have acceptance criteria which elicit three outcomes:

  • more stories for action to be taken as a result of the research,
  • means by which the said research will be shared with the sprint team and
  • stories for how the research will be shared with our community (usually via this blog site as a post)

The really interesting lesson learned for me during Sprint 0 in this instance was the challenge of reminding everyone – our team and the student team alike – how necessary this high level planning is, if they had been working in a waterfall project construct we would still be gathering requirements, would be yet to start design and it would be weeks before they get their hands on tools and code. It’s been funny how quickly that perspective is lost.

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Albert Einstein

Focus, Focus, Focus

When everything is new it’s hard to stay focused. The tension between our project requirements, the WelTec course requirements, learning new things for their CV’s so they can find jobs after this semester, learning to work as a team etc etc have created a additional workload and opportunities for distraction so finding techniques to stay focused has been really important.
I’ve asked the student team to take 5 minutes every day to ask themselves these questions:

  • Are we working on the most critical activities?
    Are we learning?
    Are we making progress towards our sprint vision?
    Are we sharing the workload?

Sprint visions are a contentious issue within my (OptimalBI) team. The natural tendency is to list the stories the team identified to work on and state a combination of those as the vision for the sprint. I have a lofty goal that a sprint vision can be stated in terms of – how we will know we were successful – and the stories delivered to done-done are a supporting mechanism for that vision. For example a sprint vision might be “we will successfully load one dataset”, this will require a raft of stories from technology selections to tested code, all of which culminate in achieving the stated vision. This doesn’t change show-n-tell which requires demonstration of every story done-done, it just helps the team and product owner focus on an outcome.

Just to conclude

I do worry the student team might be feeling like they are in an episode of Myth Busters at the moment, we give them so tools and techniques, let them go (remembering they are accountable for their own project outcome) then reel them back in and press reset based on the lessons learned. Over the next few weeks I expect the reeling in to happen less and less and they will find their feet, feel confident and enjoy the empowering model of two week sprints! Happy sharing, Vic.
happy student team

Submit a Comment

Your email address will not be published. Required fields are marked *