Last week we held an Agile 101 session at Pozible HQ for the five change makers we will be working with this coming June. This was the first time we've held this special session and I think it was well worth doing. It's important for a number of reasons. It helps change makers who are new to tech to understand how software is build and how the hack day participants, specifically the software developers, are likely to work. It also enables the change makers to get involved very early in the process and allows them to feel more confident about communicating with, and leading their development teams. I love how the RHoK Leadership continually works towards improving how RHoK operates, and is always looking for better ways to make sure that change makers have a central role.
The session was led by out intrepid leader Angus Hervey (@angushervey), Tim Elliot, and Mandi Hicks (@ZombieGRl64). After meeting our five newest change makers, Tim and Mandi gave a really fantastic presentation on Agile 101 & Lean Principles. Starting with the various roles and processes in software development.
the various roles in software development:
- configuring infrastructure and environments
- writing code
- graphic design
- user experience design
- business analysis
- product management
- project management
By definition hackathons don't include all these processes, the idea being to get a "quick and dirty" solution out the door in a short period of time. It's less about robust software development and more about building a useful prototype that adds value. But revisiting the various roles in software development is useful for reminding ourselves of how software ought to be (and usually is ) done. As a change maker it also gives you a chance to think about what aspects of the hack are the most important, what the priorities are, the level of planning required for each step. It's also an important part of planning for further development.
Mandi talked about Agile and Lean Principles. Not too long ago I had a bit of a moment of enlightenment when it comes to agile. In astronomy research, there are those that agile and those that don't, or rather those that do the exact opposite – whether they realise it or not. I think I'm firmly in latter and I can't help but wonder if the most successful astronomers are the former? The following list nicely summarises the core principles.
the agile principles
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity — the art of maximizing the amount of work not done — is essential
- Self-organizing teams
- Regular adaptation to changing circumstance
Essentially the idea is to develop a product rapidly by breaking things into smaller parts, where each part is intrinsically high-value. The process also requires continually seeking information and feedback – often – and then refining work at each step. Achieving this also requires software developers to embrace the so called "fail often, fail fast" mantra. The goal is to maximise value not only at the "end" of the process but throughout, and it provides a method for measuring progress in the context of extreme uncertainty. Ultimately the idea is figure out the right thing to build – the "thing" customers will want and will quickly pay for, so the success of this model is in it's ability to identify the right solution early on in the process.
In many ways this is the opposite of academic research – aside from the fact that it's much more exploratory in nature and you don't always know what the end goal is. In academia, there tends be an assumption, or expectation, that postdocs are the "experts" in their field, fresh out of their PhD. "Failing" is rarely encouraged (or at least, admitting and perceived negatively, and for these reasons early career researchers are afraid to ask for (or appear to need) too much help. After all the years of training postdocs are supposed to be self-directed, self-motivated and self-sufficient. To some extent large collaborations can mitigate this thinking. Of course there are many researchers who do exhibit agile principles. Researchers who exhibit agile principles make use of their networks, are resourceful, change or work on multiple projects (large and small), and are willing to admit, relatively quickly, when they are in need of help or require other skills. Anti-agilers are likely to be researchers who persist on seeing a project through to the end, well after it's deemed worthwhile, or persist with badly executed data analysis or code because they can't bear to let go of work that represents significant time and effort. Understanding agile in software development context has enabled me to reflect on past roadblocks and has changed the way I approach new projects. There is no greater destroyer of creative potential than the misguided decision to persevere with something that isn't going to achieve what you want.
lean principles and the business model canvas
"Lean", is a systematic method for the elimination of waste. The idea is to focus on the aspect that adds most value by reducing everything else. Lean manufacturing is a management philosophy derived mostly from the Toyota Production System (TPS). For hack projects, the lean principle can be invaluable. Before and during hackathons, hundreds of ideas bounce around the room and with infinite possibilities (other than time) it's tempting to want to do everything. In reality a successful hack project is more likely to be something that is simple, has a clear purpose, and has high-value with minimum effort. This is where the idea of a Minimum Viable Product (MVP) comes in to play. A product that is a little fun to use, feasible, and valuable, is much better than something that is technically perfect, but not terribly interesting or useful. A really useful tool that helps identify what will add the most value and how best to achieve the end goal, is the Business Model Canvas (below left). It's essentially a visual tool to identify developer and user motivations, key activities and resources, and long-tern sustainability (in the event of further development). A simpler version of this – one that is ideal for hack events – is The Product Canvas (below right).
Developing user personas are another really useful way to figure out what you are trying to achieve. We strongly encourage our change makers to go through this processes. It can help to mitigate unrealistic assumptions about the target audience and it can really help teams to develop the right type of solution. You can sketch personas out on a piece of paper, they needn't be fancy. However if you're looking for a really nice online tool to quickly create personas and share them with your team then I suggest trying UserForge. It's free, simple to use and quite stylish. A good tool to get you in a web development mood.