Category: Week 4 – Critical Reflection & Journaling

Posted on

Introduction To Agile

I have experienced quite a diversity of organisational cultures, particularly during my 17 years as a consultant, but Agile is new to me.

The interview with Belinda Waldock provided in the course materials provided a very high-level flavour for the ethos of Agile, and I learned that Agile was an alternative and flexible approach to project management, but I needed a far more detailed insight, in order to get a good feel for what Agile actually is, and the benefits to be realised.

Initially, my search provided plenty of other resources which offered a similar ‘all sizzle, but no sausage’ level of detail (and invariably had a book, consultancy services, or something else to sell) but I needed to get into the mechanics of Agile for the sake of my comprehension.

A study group member recommended a talk “Agile Project Management With Kanban” by Eric Brechner. This was a very informative walk through of a Kanban system in action, but advocates Kanban as the sole technique needed to be Agile, rendering the scrum redundant. Having only an inkling as to what a scrum might be at this point, I was in no position to agree, or disagree with this point of view. So the search continued..

I finally found a talk, “Introduction to Agile – Transformation, Best Practices and Common Problems” by Maarten DuPont, that discussed Agile to the perfect level of detail to put some meat on the bones for me.

The Agile Manifesto

The Agile Manifesto promotes 4 fundamental values for a flexible, quality driven management process that focuses on creating products that meet consumer needs and expectations:

  1. Individuals and interactions OVER processes and tools
  2. Working software OVER comprehensive documentation
  3. Customer collaboration OVER contract negotiation
  4. Responding to change OVER following a plan

The 12 principles of Agile

Agile is further underpinned by 12 principles, designed to provoke an efficient, customer-focused working environment that aligns to business objectives, and is quick to pivot in response to changes in user needs and other market forces:

  1. Satisfying customers through early and continuous delivery of valuable work.
  2. Breaking big work down into smaller tasks that can be completed quickly.
  3. Recognising that the best work emerges from self-organised teams.
  4. Providing motivated individuals with the environment and support they need and trusting them to get the job done.
  5. Creating processes that promote sustainable efforts.
  6. Maintaining a constant pace for completed work.
  7. Welcoming changing requirements, even late in a project.
  8. Assembling the project team and business owners on a daily basis throughout the project.
  9. Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behaviour accordingly.
  10. Measuring progress by the amount of completed work.
  11. Continually seeking excellence.
  12. Harnessing change for a competitive advantage.

A Typical Agile Process

As Belinda Waldock says, Agile, by definition is not a rigidly set methodology, rather an adoption of the manifesto and principles to incrementally deliver customer requirements. That said, DuPont delivers a diagrammatic representation of a typical Agile process:

  1. The Vision
    • The customer provides a business case for their requirements from the team at that point in time.
  2. The Product Backlog
    • The business case is broken down into smaller chunks and prioritised.
  3. The Sprint Backlog
    • Takes a manageable portion of the product backlog to be implemented during the next sprint
  4. The sprint
    • A predetermined period of time (usually 1-4 weeks long) that is dedicated to achieving all of the tasks contained within the sprint backlog.
  5. Daily Scrum
    • A short (usually 15 minutes), strictly focused daily meeting where each team member take their turn to state what they did yesterday, what they will do today, and whether they foresee any blockers (obstacles/impediments) that might stand in their way (which become the responsibility of the Scrum Master to resolve in good time).
  6. Product Increment
    • When the sprint is complete, whatever has been achieved should be presented to the customer for feedback.
  7. The Sprint Review
    • A reflective analysis of the sprint
  8. Sprint Planning
    • A reassessment of requirements and their priorities, and selecting the tasks to be completed during the next sprint.

While I feel that I have achieved a level of theoretical understanding of Agile, I still have lots of questions and a curiosity for the practical nuances of adopting an Agile management approach. I realise that many of these questions can only be answered by immersing myself in the practicalities of an Agile project context.

Having very little experience with tech companies (a 3 week project with Siemens), and no experience within a tech team, goes some way to explaining why I haven’t crossed paths with Agile before now. But I can see that the successful adoption of an Agile approach to project management depends upon a conducive organisational structure and culture. The majority of the organisations that I have worked with operate a traditional, functionally hierarchical structure, with a vertical chain of command and clearly defined specialist departments (or stovepipes). One or two have structured their company in a matrix style, with horizontal and vertical reporting lines, with functionally specialised teams that also focus on a particular segment of their market. I assume that both of these structures would experience a level of political friction and conflict with an Agile approach, relating to how clearly defined and rigidly implemented the boundaries and reporting lines are. As we continue to progress into the digital age, more and more organisations (with certain industries, such as Tech and Banking leading the way) are realising advantages by removing the boundaries, and operating beyond the edges to enable sharply customer-focused agile teams to deliver optimised value.

Posted on

Personal Case Study

I have a commercial background, but I’m on the MA Creative App Development course because I want to be well equipped to create my own startup venture, with a mobile app sitting at the core of the business and I want to feel confident that I can launch and grow that business into a success story. So, I’m using the course to develop the full range of skills and competencies that I need to become a developer of great mobile apps.

Skills & Competencies

I started by looking at the key skills and competencies that a great app developer needs, and through brainstorming, with some internet research, I found myself developing a model to help me to see where I need to be.  This is how I see it:

The skills, group nicely into a trinity of families:

  • Technical skills – so that I can create and build an excellent product
  • Business acumen – so that I can identify market needs and create a business model that successfully delivers a financially viable solution.
  • And artistic talent – so that I can deliver a user experience that supports the brand, creates another competitive selling point, and nurtures adoption and loyalty.

And I rank them in that order of importance for me.

Each of the skills families is an umbrella for an array of hard skills, each with its own level of relevance and priority in terms of how it impacts my own short, medium and long-term objectives.

And all of this is supported by a range of soft skills.

I conducted a subjective self-assessment of my starting point, based on my achievement to date and peer comparison, and the green triangle represents my perceived current capability as an app developer.

I intend to get my business venture off the ground on my own, initially, and gradually build my team of specialists around me, as and when necessary, and so I need to spend the next 2 years bringing my score for each of the skills families to at least a 9.  The red area represents my currently perceived skills gap.

The arrows at the end of each scale, point toward infinity, representing my appreciation for endless learning opportunity, in order to exploit new technologies, rapid adaptation of developing industry trends, and satisfy ever-changing consumer demands.

My priorities for the course lie with the development of my technical skills.  It’s imperative that I bring those up to speed as quickly as possible, so that I have a solid foundation for the rest of the course.

I may not have an IT background, but I do bring some solid transferrable skills.  I’m very analytical and pragmatic, with a good balance of both logical and creative thinking for problem solving.  However, building this model brought a realisation that I hadn’t fully appreciated the enormity of the task ahead, and just how much of it is completely new to me.  I’m viewing this as a stretching, but achievable challenge that I’m fully committed to, but, at times, I’ve felt a little overwhelmed by the size of the skills gap, and there is a degree of imposter syndrome that I’m currently wrestling with. I just need to keep a calm head, eat this elephant one bite at a time, and trust in the support network and resources that the course provides, to help get me there.

The App Jam

The week 3 app jam was an end-to-end development exercise, with a theme based on the words “guide”, “opponent” and “restricted”, which were generated using VNA cards.  This was an opportunity for me to draw on everything I’d learned, and assess my strengths and weaknesses within that context. I knew from the outset that the jam had come far too early in the process for me, as I lacked the necessary technical skills.  Although, I hadn’t discounted the possibility at that point, I knew that building a fully working app wasn’t a realistic goal for me. So, I primarily focused on what I could learn from the process of the jam, with the aim of creating a paper prototype and then building a fully working app if I could improve my skills sufficiently in time, but this became a secondary concern for me.

As expected, I didn’t get to build the app.  But I did get a good experience of the process, taking away some key lessons:

  • The right tools for the job

I need experience with the best tools for the job.

  • Flutter

    • I tried to get some Flutter experience before starting the jam.  I’m now content that Flutter is the best development strategy for me, as it allows me to develop for both Android and iOS platforms with a single code base, and it’s reported to be relatively straightforward to learn.  However, it’s completely new to me and there just wasn’t enough time to get to grips with it in any real depth.
  • Dart
    • Flutter uses the Dart language, and so a solid general understanding of that will also be highly beneficial for me.
  • Process flow tool
    • During the creative piece from week 1, I had identified a need to find a more appropriate tool than PowerPoint to draw up process flow diagrams, but I hadn’t managed to do this in time
  • Wireframing tool
    • and it’s a similar situation with wireframing.  I did look at InVision as a possible tool, to help planning screen layouts, but learning how to use it was time that I couldn’t afford if I wanted to achieve anything else before the deadline. So I reverted to PowerPoint.  It does deliver aesthetically pleasing results, but it’s time consuming and becomes fiddly when working with small detail.  Maybe I should have settled for hand drawn sketches? I’ll explore this further.
  • Time estimation

I based my plan for the jam on what I’d learnt from the week 1 creative piece. While the structure was, on the whole, fairly sound, my time estimations for each phase weren’t always very accurate.  I compensated for slippage by adjusting and capping subsequent tasks to stay on track.  Experience will help with this, but I’ll also look to adopt some Agile principles to improve my project management skills.

  • Select projects that inspire me

I generated a list of theme ideas, and decided to pursue my “Quick Cook Challenge” app idea, as it was something that I thought I might use myself, and some rudimentary research identified that there might be an opportunity in the market for it.  But, after working on this for a few days, I noticed myself beginning to procrastinate, which told me that I wasn’t as invested in the concept as I’d first thought, and I had to be quite disciplined to make progress with it.  I might have avoided this by generating a theme that I could really get excited about, had I afforded more time for the theme generation phase, and applied a more strategic concept assessment and selection criteria.

  • Subconscious thinking is valuable

Many of my better creative ideas happened while I was doing something completely unrelated, with thoughts just popping into my head from nowhere.  I need to capitalise on this and build purposeful breaks into my plan at the appropriate times, to allow for this subconscious ideation to happen.

Taking all of this into account, my main objectives for the remainder of the module are:

Objectives for the rest of module 1

  1. Programming

Before the next Module starts, I will use Flutter to build a working prototype for the “Quick Cook Challenge” app, from the jam. I will apply the principles learned as I go through 6 Flutter and Dart tutorial courses, to create a fully working prototype.  I will dedicate 18 hours per week to this, as it is essential that I can comfortably build an app of a decent standard, for the rest of the course.  To further improve my capability, I will also read “Think Like a Programmer”, and engage with the Flutter community, by connecting with relevant individuals and groups on social media platforms, as well as sharing ideas with others within the study group who also have an interest in Flutter.

2. Version Control

By 26/04/19 I will be comfortable using Git and GitHub for version control, both from the command prompt, and through Android Studio, so that I am well prepared to work on collaborative projects.  I will spend 2-3 hours per week taking 2 video tutorial courses.

3. Development tools

Before the next Module starts, I will select and learn how to use:

  • A process flow diagramming tool to draw process flow diagrams more easily
  • A wireframing tool to create medium fidelity screen plans more quickly

I will assess 2 or 3 of each type, analysing the benefits over using pencil and paper, and select the ones that I feel most comfortable with, if any.  These tools could prove very useful during future app development projects.

4. Better time management

Feedback has, so far, been largely positive, and encouraging, but I’m finding myself falling behind the pace of the course, a little.  I need to adopt a more structured, but flexible, approach to managing my week, to help me to achieve a good balance of technical skills and coursework.  I’ll spend the next 2 weeks catching up, and then work to keep pace going forward, using this weekly plan, of 3 hour periods:

And this is how it all fits into my plan for the rest of the module.

Posted on

Using Journal Writing to Enhance Reflective Practice by David Boud

I found the paper “Using Journal Writing to Enhance Reflective Practice”, by David Boud,, helped me to develop my understanding of the importance of engaging in reflective practices

using-journal-writing-to-enhance-reflective-practice-by-david-boud-Download

For my own sake, I will outline here the key points that I took from reading this paper, which defines reflection in the following way:

Reflection has been described as a process of turning experience into learning. That is, of exploring experience in order to learn new things from it. Reflection has been described as ‘those intellectual and affective activities in which individuals engage to explore their experiences in order to lead to new understandings and appreciations.


Boud, Keogh and Walker 1985: 19

The following points are made to elaborate on the the ways in which reflection is an effective learning aid:

  • Reflection is about taking the raw, unprocessed material of experience and engaging with it to make sense of what has occurred
  • Exploring often messy and confused events and focusing on the thoughts and emotions that accompany them.
  • Events and experiences are recorded, processed and performed.
  • The basic assumption is that learning is always grounded in prior experience, and that any attempt to promote new learning must take account of this learning.
  • All learning builds on existing perceptions and frameworks for understanding, and links must be made between what is new and what already exists.
  • Past experiences profoundly affect perceptions of what is and what isn’t important.
  • Much of the benefit of participating in any event derives from how it can shape our participation to suit our goals.

This paper has helped me to secure at least an overview of the main purposes of engaging in reflective practice through journaling.

Posted on

Getting To Grips With Reflection

While the Johari Window model has been a useful aid in getting to grips with critical reflective journaling, and feedback received to date indicates that I am moving closer toward satisfying the requirements of the assessment criteria, I am still not completely confident that I am getting this right. However, this week’s course material (which I think I might have found very useful in week 1) and the relevant recommendations on the reading list, are helping me with this, along with learning from continued feedback.

I found it helpful to interpret the video on the holistic reflection and the reflective domains into a model (above) which maps out what a holistic reflection needs to look like. I will attempt to use this in my reflective practice on order to find the right balance across all five domains. While each domain needs careful consideration when reflecting on any topic, I can see that the relative weights might vary, depending upon the nature of the subject matter in question. The skill to be mastered here is the ability to recognise where the emphasis needs to lie, in order to get the correct balance within any given context.

Posted on

Critical Reflection and Journaling

The focus for this week is on critical reflection and journaling.

I hesitate to be so candid here, and I have no intention to offend, but I understand that this is a space where I am required to say what I feel, so here goes…

If I’m totally honest, my initial instincts tell me that critical reflection and journaling are a bit of a waste of my time. At this point, it feels like an academic exercise that is a distracting nuisance, robbing me of a considerable amount of time. Time that could be better spent developing critical skills.

My objectives for this course primarily lie in gaining a good range of skills that will enable me to develop well received, commercially lucrative apps. I therefore want to spend the vast majority of my time focusing on achieving coding expertise and development best practice, as well as improving my business and design capabilities.

Considering the marking schemes for this module, I notice the emphasis on reflective practices and self-analysis. I’m sure that is by design, rather than by accident, or purely for the box-ticking sake of it, and so, I am prepared to suspend my judgement, and approach creative reflection and journaling with an open mind. I will trust the process, actively strive to discover the value in it, and see if I can make critical reflection and journaling beneficial for me. I’m not saying that I’m right to feel the way I currently do – I’m merely saying this is how it is at leas at this point, but I am open to having my opinion changed.

I am new to critical reflection journaling, and for the past 3 weeks, I have struggled with it. Knowing what to share, and how to share it within this arena is not something that has come naturally to me, and I think that I have found it difficult to strike the right balance.

This situation has brought to mind the Johari Window model ( Joseph Luft and Harrington Ingham, 1955 ), that I was introduced to many years ago during a training course. The concept resonated with me at the time, and has stuck with me ever since. The model is used as a basis upon which to examine interpersonal and intrapersonal communication, and how relationships can be effected by the appropriateness (or otherwise) of what information is and isn’t shared between relevant parties.

The model provides a simple framework for us to think through the consequences, and decide which box is most appropriate for a piece of information, within a specific context. A lot of social media users would do well to consider the Johari Window model before posting!

I’m still not entirely convinced that much of the content of this post shouldn’t have remained in the ‘Hidden’ box (i.e. kept to myself), but, if nothing else, I can always learn from the reception it gets.

Design a site like this with WordPress.com
Get started