I planned to write this second post on agile eLearning development about the backlog and estimations. But when I was preparing this post I realized that I had to cover something else first; Culture.
The difference between a classic waterfall approach and an agile one is way more than applying a different set of tools and techniques, it is a different state of mind. For starters it is a very different way of control and steering. The best way I can explain it is by looking at a management theory called output management.
In 1998/1999 I followed a course in Change Management. It did consist out of a series of three-day seminars. Each seminar we had a guest teacher from the field of (change) management. One of the guest teachers was Filip vandenDriesche. He is the author of the book ‘Leading without commanding’, it was originally published under the title ‘The input- output manager’. For me his theory describes the very essence of management but it also applies to an agile approach. The next image is the heart of his theory.
Filip states that the main challenge of management is the conflict between strategy and operation. There are two contradicting pyramids. The “management funnel” and the “conflict pyramid’. Both cover three stages (strategic, tactical and operational). On the strategic level (problem and goal) the chances of conflict are small, but if you have a conflict it runs deep! On a tactical level (criteria) the chances of conflict are increasing but on a operational level the chances on a conflict are the biggest. Therefore Filip concludes the following: A manager should be authoritarian on the strategic and tactical level. But on an operational level manager should accept any solution that meets his criteria. In other words keep away from the ‘how’.
I have been working as a manager now for 15 years and I found out that it works. But more importantly I found out that it is about trust and not about control and therefore it is about the culture of your company. Not many companies are build on trust and the recognition of the skills and capabilities of all the participants. As a manager you have to set goals and requirements, but that is it. You need to trust your team that they will come up with a solution, and as long as the solution meets your requirements you should accept it.
ELearning
How does this apply to eLearning? It works like this. The manager (or in case of a project, the client) has to define the problem and set the goals. (The goal is the positive flip side of a problem; ‘we don’t sell enough’ vs ‘We need to sell 10% more’). All the people who are part of the process must recognize the problem and accept the goal. This is buy-in number one.
The problem/goal is a business problem/goal of your company or client and if you or any of the team members don’t buy it, you have a big problem. The chances of this happening are small. After the problem/goal is defined the manager sets requirements for a solution. Requirements can be anything from time, costs to quality and everything in between, as long as they don’t dictate the solution. A requirement should not be: ‘the course must be in HTML5’, but ‘the course should run on all mobile devices and operating systems’. Filip says a manager/client has to be authoritarian on requirements, but I don’t completely agree. The whole process only works if the team that has to create the solution accepts the problem/goal and the requirements. By accepting both they become responsible for the solution within the given boundaries. I found that before acceptance some negotiations on the requirements can/will happen. For example with the goal ‘the course should run on all mobile devices’ the team could come back with the remark that given the time and financial restraints they can do it on IOS and Android only or they need more budget and time, or that they can do it if they have special software available. This second buy-in is all important, by accepting the problem/goal and requirements the team is now the proud owner of the problem, they need to come up with a solution within the given requirements. Thanks to this you empower them, you recognize their expertise and skills and basically you show as a manager/client that you trust them. On the other side the team has to deliver. They have committed to creating a solution and if they fail, it is their problem. They can’t say that they didn’t had enough resources or time, because they have accepted the requirements. In that case they made a mistake accepting it. On the other side the manager/client has to accept every solution that meets the requirements. If the manager/client is not happy with the solution obviously there was something wrong with the requirements.
But there is more to agile. It is also a very different attitude to planned development. As I will describe later in more detail, the customer demands are captured in ‘ user stories’ that are prioritized. The developers will commit to these user stories and build them in short sprints (periods of one or two weeks) and then they will demo them. In our case the demo is done to some colleagues (product owner, CEO, instructional designer), but very often partners or customers will also attend these demo’s. The goal of the demo is for the development team to show how they solved the user story within the requirements. The product owner is the person that can officially accept a user story. The cool thing is that seeing the implementation of the user story can trigger some things. Sometimes seeing the solution brings on new ideas (and will lead to different or adjusted user stories) and sometimes we decide that this solution is good enough (although there are more developments planned). An example we had at easygenerator is our version control, we had a whole bunch of user stories ready, but after the implementation of the first two stories (create a new version every time a page is saved and be able to roll back to a previous version), we decided that this was ‘ good enough’ as a solution for our business need. We decided to leave it like that and bring out the new version with this functionality. And it is still there to this day, it does it’s job and it satisfies the users. So sometimes it will be so agile that you stop earlier than planned. This is just an example what an agile state of mind is.
Conclusion:
Working in an agile way requires a certain culture. You need to have responsibilities in the right levels (as I tried to explain using the output management approach. Teams should work as a whole accepting responsibility to realize user stories within the given requirements and a project can shift during the execution (maybe even will shift) and can even be ended earlier than planned when the goals are reached.
This post is part of a series on agile eLearning development:
- Post 1: Review on Michael Allen’s book ‘Leaving ADDIE for SAM
- Post 2: Agile eLearning development: business goals and road map
- Post 3: Agile eLearning development (2): Culture
- Post 4: Agile eLearning development (3): Best practices, Demo’s, user stories and backlog
More post will follow over the next few weeks.
The Learning 2019 conference
I have been to a ton of learning conferences but this will be my first time at #learning2019. I’m looking forward to it and I’m planning to report on all interesting sessions via this blog.
