What’s Next?

Week 12 brings us to the end of the first module, GAM710. I know this is oxymoronic, but it really has been a long 12 weeks that have passed in the blink of an eye. GAM710 has been very challenging (partly due to the breadth of study, and partly due to setting the bar high for myself), but I have enjoyed it and learned a lot. Some of the SMART goals that I set along the way have already been achieved, while others are still a work in progress. Some I intend to have completed before the next module begins, but I have intentionally included some longer term goals and aspirations that will continue to progress throughout the rest of my MA studies, and beyond. These include:

Flutter Development

I am now in a position to begin building a functional prototype for my “Quick Cook Challenge” app. I am confident that I made the right choice of development strategy and I’m looking forward to investing more time in honing my skills in this area to move along the learning curve in pursuit of mastery. Now that the intense period of reflection has come to an end, I can take a lesson from Adriel Wallick in her video talk “Game a Week: How to Succeed, Fail and Learn”. I need to put in the development hours to make the progress that I’m looking for.

I set a SMART goal to investigate prototyping tools for designing screen mock-ups, but now that I have had the opportunity to gain some familiarity with Flutter, I have concluded that best strategy here is to use rough pencil and paper sketches and then jump straight into Flutter, rather than involve an intermediary tool for high fidelity images.

I do intend to spend some time learning more about source control before the next module commences, but I’m now not overly concerned about reaching any particular level of expertise. As long as I can get a handle on the basic elements, I can learn on the go, on an as and when required basis.

Agile

Agile is a new concept for me, but I feel that, during this module, I have grasped a solid theoretical understanding of the general mechanics involved. I am looking forward to immersing myself in a situation to experience the practical application of the project management methodologies.

Through some trial and error, I feel that I now have a better handle on the effective use of a Trello board to organise my work schedule, and I intend to take a more disciplined approach to sprint planning and review, going forward.

Commerce

New practices, tools and techniques have emerged since I first set out on my corporate career path, and while I have some level of familiarity with them, this module has persuaded me to delve deeper into the likes of Lean Startup Methodologies, Business Model Canvas and Strategic Digital Marketing over the duration of the remainder of my MA studies, so that I can embrace them for the benefit of my intended startup venture.

Emerging Technologies

Data science – big data, machine learning and predictive analytics hold particular interest for me. I have a lot of data analysis experience and enjoy unleashing the power that good data holds. I am aware that these are huge areas of study, but I intend to take my analytical talents to the next level by exploring these areas in more detail, with the purpose of creatively integrating these technologies into the app product that I eventually build for my intended startup venture. This will dramatically improve the value offered by my business model.

I am looking forward to getting stuck in to some practical development work in GAM730, and it will be great to gain some practical experience of working on a collaborative project managed with Agile principles and techniques. But, before that happens, I’m really looking forward to enjoying some downtime to overcome the ‘extreme reflection fatigue’ that I’m currently battling!

Trello Board Update

That’s much better!

Now that I have visibility of each task (rather than at a weekly topic level) I can see exactly where I am.

I can now use this board to properly plan and review my weekly sprints, and organise myself more efficiently, and so I consider my SMART goal from week 9 to be achieved.

It’s also quite nice to be able to slide each card to the right, as it helps to garner a satisfying feeling of accomplishment.

Project Management Tools & Techniques

This week’s materials cover some aspects of managing large scale projects. There was a comparison of the (considered somewhat outdated) waterfall approach and the Agile approach.

I spent the last 17 years as an independent Excel/VBA Development Consultant, and my approach to each project was very much in line with the waterfall approach, as the video demonstrated. I can see many advantages to be gained from taking an Agile approach instead, but within a consulting context, I suspect that it would be very much dependant upon the culture of the client organisation as to whether they would be willing to accommodate that. In my experience, clients want to hold the consultant to a clearly defined set of objectives and a predetermined budget, and I’m fairly certain that the clients that I have worked with would never have achieved sign-off for a business case that didn’t explicitly dictate these things. That said, it was very often the case that once the client began to learn of the potential for additional functionality for the model or system that I was building, they would then set to battle for sign-off on an amended and extended business case. This process often makes for a less than efficient development process, but at the end of the day, the client gets what the client wants.

Having done a significant amount of self-directed investigation into the mechanics of an Agile approach in week 4, I won’t go back over the ins-and-outs of an Agile process with this post. However, as I’ve said previously, Agile was not something that I had come up against prior to this course, and while I’m confident that I understand the theoretical process, I’m keen to become a part of an Agile run project as I don’t believe that you can fully appreciate the practicalities of such a situation until you have been a part of it in operation. I’m sure that I’ll have plenty of questions when the time comes.

Kanban With Trello

I have used the Trello tutorial to set up a board (essentially a Kanban board) for my coursework, but it isn’t currently working for me.  I see the benefits of using a board, but I’ve structured it in a way that doesn’t provide clear visibility of the tasks.  I used a card for each week of the course, with tasks listed within it, making it difficult for me to see task-level detail.  Consequently I haven’t used or updated the board since.

By 14th April I will have a restructured Trello board, using a card per task, and grouping them into relevant weeks, and categories with a colour key, to give full task-level visibility.

A well-structured Trello board will help me plan and implement weekly sprints to manage my progress more effectively.  Moving cards to the right will also provide an element of motivation for me.

I will add a card for each of the tasks from the entire module and assign a colour to categorise it, to group tasks according to the course week, or goal that it relates to.  I will then prioritise the tasks and move each card to the appropriate status lane.  I will then continue to use the board on an ongoing basis to chart my progress. Tutor/study group feedback might also prove helpful. So, I will commit to the following SMART goal:

Specific

I will improve my project and time management by restructuring my Trello board, using a card for each task, categorised with a colour key.

Measurable

The success of the restructure will be measured by how effectively it serves me going forward. Further adaptation will occur as part of the ongoing board management process.

Achievable

Time is the only constraining factor, but the restructure should only take me around 2 hours.

Relevant

A well-structured Trello board will help me to better manage my progress throughout the course, and beyond.

Time-Bound

This will be achieved by 14th April

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.

Design a site like this with WordPress.com
Get started