™The agility of a startup, the experience of an enterprise
Want to know a bit more about how we get things done here at Beestar? Here at Beestar HQ we love agile principles and apply them to our daily work. For those of you still in the dark about what agile is (really, where have you been?), you can think of it as a development model that allows for flexibility because of the iterative way of dealing with new requirements and new ideas. Agile promotes getting your hands dirty and just getting on with the thing you are building instead of spending too much time preparing for getting to work on it.
The exact opposite of agile is the waterfall model, which breaks each step of development up into a segment that can’t be moved to unless the previous segment has been finished. Each segment is planned carefully and is under full control of the project manager and/or line manager. It doesn’t allow for changes to happen later on in the (development) process, which puts additional stress on documentation to be correct. To be honest, us Beestarians flinch when we hear the word waterfall. We find it so wholly unacceptable that we daren’t even say it out loud. Sort of like how Harry Potter calling the black wizard dude ‘The One Who’s Name Shall Not Be Mentioned’. You might wonder why we have such strong reactions to it. Well, it’s really quite simple. In software development as in all other things, anything can go wrong even if you plan extremely well for them. A super good plan does not guarantee a super good outcome. The best plan in the world is not going to mean that it will go well. This doesn’t mean we don’t plan at all, we just don’t over-emphasize.
Creating a product
In creating new products, for example QuASP™, we tend to use an Agile technique to create a story map, which is sort of like a treasure map, but without the treasure part. This includes defining end-user profiles (‘who are we creating this product for in the first place’) and the high-level functionality. These high-level functions are then broken down into smaller chunks which are placed below it in order of priority. The final step is to draw a giant horizontal line to determine which bits are going to be in which releases.
The story map that is created forms a ginormous piece of artwork on our walls and functions as a constant reminder for what we are working on. It also helps us to remember the thought process that led us to the decision of developing whatever it is that we are developing at that point in time.
If you are interested in trying this out for yourself, I suggest reading Steve’s article on creating a storymap, or stay tuned for more posts on the topic of story mapping in the near future by adding your email to get automatic updates.
Keeping track of work
Because there are also tasks that don’t belong to the development of a product we need to keep track of all the things going on. We aren’t all constantly working on improving the product, some of us need make sure that suppliers are paid and we keep in contact with our Twitter followers (are you one yet? Let’s connect!). For that we use a digital task board from the super-duper guys over at Kanban Flow. They basically provide a digital board on which we can add tasks and subtasks and assign them to team-members.