One of the people who responded to my posts on agile development is Ken Taggert, He is developing an Ipad app (Chatty Kidz) which combines video conferencing with educational activities for kids. He just launched a kickstarter project to find funding for the further development of the app. Nice project I can recommend it to you. He shared his experiences on agile development with me and I thought that that would add to my story, so here it is.
Reduces the amount of up front documentation (i.e. throw out the massive specification documents that nobody read anyway)
When starting a new project using a waterfall methodology you need to write your detailed specifications; a costly, laborious and boring job. The customer then reads through the details and signs off on the specification, approving the next step so development can begin. Yet in reality things do not really work to the plan! The customer does not read ALL the specification, they may read the bit they care about but the rest they skip through and approve the document. Problems crop up later in the project when a particular feature is tested and the client says ‘that’s not what I want’ only to discover it was detailed in the specification. In other scenarios the specification was maybe wrong or not detailed enough so the customer did not interpret the resulting feature exactly the same as the development team did; the difference is only identified when testing begins. To top all this off things change as progress is made in any project! Someone will have a better idea, a problem changes things downstream, etc, etc; especially in the larger projects.
Here at Chatty Kidz we use the Agile methodology where you can avoid the need to write huge, detailed specification documents – a massive plus for any Business Analyst! But it is not as simple as doing nothing either, you have to still communicate the business needs for the software solution to be developed (developers cannot read minds – yet ..).
We start with the high level wish list, simple statements such as ‘a new user can register on the website’; in Agile this is known as an EPIC. We prioritise all EPICS, i.e. what’s most important goes to the top of the list.
We pick the top EPIC and list all the relevant USER STORIES, these are still short and punchy but drill into the detail such as ‘a new user can click the REGISTER button on the homepage’ & ‘the new users email address must be validated before being accepted’. Each user story should not be more than 2 or 3 days development effort for a single developer allowing you to easily estimate the effort required using STORY POINTS (can drill into this but maybe link to these points online – there is loads of info).
We prioritise the User Stories and start development, we aim to deliver ‘something’ to the customer/user at the end of every sprint. So they can test & provide the valuable feedback, we listen and use this information for the next sprint. So we can change if need be when something more important comes to our attention.
Overtime we incrementally improve what we have built so far, adding new features & functions to the Chatty Kidz platform with each successive sprint. We save heaps of money by developing cheap working prototypes & getting them into the hands of real users. We listen to their feedback & begin work on the next release, deploy another incremental improvement at the end of the next sprint – rinse & repeat. NOTE: we use Jira to manage this process
Manage your budget better (i.e you can be more flexible as the project progresses, the vast majority development projects change tact anyway as they progress which caused havoc with budget estimates fixed in stone before the project even started)
In a waterfall project you use the detailed specification to estimate the project costs, these are approved and the project manager must manage those developments within the approved budgets – things go wrong eventually as many details were estimated incorrectly 10 months earlier.
At Chatty Kidz we still estimate the allocated budget to be spent on specific features, but we know it is not detailed nor accurate. Its simply how much we are prepared to spend at that point in time. As we have documented lots of user stories we keep prioritising them and developing them until we have exhausted the approved budget. Any user stories which are still left in the list remain there until some future point in time when we do have more budget. For example the next module may have been a lot easier that we expected so we can include some user stories missed from the previous sprint.
Yet the opposite is also true & often difficult for the project customer to grasp, if something was more complex than expected & consumed more money or new high priority user stories have been added during the course of development. The budget does not magically increase, the team must stop when the budget is consumed. They can apply for more budget to finish off some important items, but they do not blindly continue spending money and blow the project budgets because the project controls are so much better and managed at a useful granular level.
Produce a better product (deliver something into the hands of real users earlier, get them involved in the testing process earlier and fix them long before the product launches)
In a waterfall project the project first designs something on paper, then builds it over the life of the project. Towards the end the users get their hands on the resulting product when the testing phase begins; this is often where it hits the fan because it is only now the user/customer can see things look different to what they expected from endless 100 page specification documents and endless boring design meetings held at the start of the project. They have not been involved for the last 10 months as the build phase was completed by the project team!!
At Chatty Kidz we use Agile and involve the users/customer from start to finish of the project life-cycle. We do not overload the user at the start of the project with loads of design meetings and thick specification documents, instead they attend meetings every 2 weeks (the length of our sprint) and they are asked to focus on a specific feature. It is a lot more manageable for the user because we are only asking for a limited amount of their time! We do not ask them to review massive detailed specification documents because we created the user stories together. There is less worry & stress about budgets because each 2 week sprint has a very clear budget estimate that’s not that large compared to the entire project – its a manageable chunk for everyone.
We involve the users/customer throughout the entire life of the project as they have to test the real software resulting from each 2 week sprint, again it is not an onerous task. Because there is not a massive amount to test, we are productive in each 2 week sprint but it is only going to take a user a few hours to test it & provide their feedback – easy.
There are no surprises waiting for anyone as they are involved in the incremental improvements made to the software sprint by sprint
NOTE: we use testflightapp to distribute the ALPHA versions of the app to the test teams, allowing us to get feedback even earlier.
This post is part of a series on agile eLearning development:
- Review on Michael Allen’s book ‘Leaving ADDIE for SAM
- Agile eLearning development: business goals and road map
- Agile eLearning development (2): Culture
- Agile eLearning development (3): Best practices, Demo’s, user stories and backlog
- Agile eLearning development (4): Planning and execution
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.
