For becoming more and more agile
If you are not at all familiar with the term “agile”, please read through the Agile Manifesto and its principles first. You will probably agree with the manifesto. But from our point of view, it helps to dig a little deeper. Of course, we’ve set up the environment already for agile software development, so we
- have cross-functional and multi-disciplinary teams
- do paper prototyping and usability testing upfront before we develop
- have daily status meeting
- always work in a test-driven way
- have continuous build and integration
- work in short iterations and regularly deliver results
- have abandoned waterfall thinking long ago
Every single member of Catalysts can grow to become more and more agile.
Look at the following list to get an initial understanding of how agile you are and where you can improve:
- Analysing before designing: Do you do a little bit of analysis and design in each iteration? <=> Do you analyse all requirements before designing the entire solution?
- Architecture: Do you let the architecture grow as you go? <=> Do you design the architecture upfront?
- Close collaboration of business and IT: Do you collaborate closely? <=> Do you hand over written documents and have them signed off?
- Discipline: Do you do what you’ve said? <=> Do you love thick guidelines and procedures that you should follow?
- Direct communication: Do you rely a lot on face-to-face communication? <=> Are there a lot of documents?
- Embracing necessary changes: Do you go for necessary changes? <=> Do you rather delay them into future releases via stiff change management procedures?
- Empowering team members to self-organize: Do you encourage your team members to self-organize? <=> Do you rather tell them what to do and control that they follow your instructions?
- Frequent inspection and adaptation / synchronization: interval of hours … days <=> weeks … months
- Immediate feedback: Do you look for and give immediate feedback? <=> Do you rather hide feedback in reports?
- Joint requirements sessions: Do you develop a common understanding of the requirements together with the client? <=> Do you request requirements specifications?
- Joint application design: Do you develop an initial application design together with the client (in an “ubiquitous language”)? <=> Do you develop the design yourself in your own words?
- Learning: Do you learn and adapt at the end of each iteration with a quick retrospective? <=> Do you have a lessons learned session at the end of the project at best?
- Managing: Do you lead your team? <=> Do you make a show of force?
- Open communication: Do you and your team speak up freely? <=> Do things wander around through the minds for weeks before being spoken about?
- Planning: Do you plan the near future based on features? <=> Do you have a detailed plan for the entire project?
- Reflective improvement: Do you try to learn from every failure and success? <=> Do you already know everything?
- Reporting the status: Dou you report often and can you trust the reports? <=> Do you only know late in the project that the project is late?
- Releasing early and often: Early and often <=> once at the end
- Striving for excellence: Do you and everyone on the team strive for excellence? <=> Do you do the best you can?
- Simplicity: Do you accept additional effort to get a simpler solution? <=> Is it enough if a solution works?
- Timeboxing: Do you define timeboxes of fixed length for meetings, iterations, etc.? <=> Do meetings, releases, etc. simply take as long as it takes?