Conclusion and Thoughts on the Retrospective
So yesterday was the day in which I performed the Agile Retrospective
and all in all I'm happy with the outcome and the overall feeling of what happened. Ultimately as in all things, I would change aspects and completely scrap others. So what happened?
and all in all I'm happy with the outcome and the overall feeling of what happened. Ultimately as in all things, I would change aspects and completely scrap others. So what happened?The final agenda/flow:
1) Introduction - 5mins
2) Activity 1 | Check-in - 10mins
3) Activity 2 | Timeline - 35mins
4) Activity 3 | Locate Strengths - 35mins
5) Activity 4 | Team radar - 10mins
6) Conclusion 5mins
I have spilt the analysis up on per activity basis to give a clear and brief overview of what I did, what went well and what didn't work so well.
Intro: Simple, brief overview of what I am trying to achieve and a few words hopefully trying to engage with people about what they should aim their minds at over the next 1.5 hours.
Activity 1 | Check-in: (15min)
For this activity I decided to purpose this question:
Reflecting on the last iteration only, if you where to describe it as a cooked joint of meat or fish, what would it be?
Obviously trying to be funny and light hearted, aiming to get the groups mind off coding and open to alternative thought patterns. (See picture below for outcome)
Activity 2 | Timeline: (35min)
Reflecting on the last iteration only, if you where to describe it as a cooked joint of meat or fish, what would it be?
Obviously trying to be funny and light hearted, aiming to get the groups mind off coding and open to alternative thought patterns. (See picture below for outcome)
Activity 2 | Timeline: (35min)
The timeline ended up being very successful as planned. This activity gets people talking and debt flowing. I made a slight twist to the standard timeline, having three types of event, Business related, Team related and Technical. Marking each card with a different coloured post-it with the aim to gather more data and insight in where things are going wrong and what factors of the business can influence the mood and productivity of the team though a 2 week sprint. Once we had classified and marked each card, then going through each point noted, asking the person who put it up to explain what they mean and then to give a tick or cross depending on if it’s good or bad.
Activity 3 | Patterns and Shifts: (35min)
This activity flows easily from the timeline due to the vast amounts of data which had been collected. After 30-40 minutes of discussion in the previous task, and talking through good and bad point it’s was now time to identify some common patterns and shifts. Many common agile issues I have read about came up, for example:
Business direction and uncertainty: The business don't always know what they want, making it difficult to complete tasks. Lots of time had been wasted having the same meeting 4 times during the 2 weeks with stake holders about what they require for the next sprint.
Lack of commitment and Business understanding: This relates to the lack of understanding without keys players which are hard to get time with. Story sign-off doesn't really complete without key figures in the business which has held back development and forced our Business Analysis to fall behind, leaving little time or know time to analysis stories and determine acceptance criteria before development starts.
3rd Parties: Suppliers and external companies blocking the final completion of projects, delaying when the team can relinquish responsibility for past 3rd party integrations and project work.
Development Process Improvements: Improvements from the team in development process, design and planning structures. Trialling different forms of pair programming
(good and bad) and having enforced design sessions before any code or interface was started, even if this is a fag'packet'design.
(good and bad) and having enforced design sessions before any code or interface was started, even if this is a fag'packet'design. Development issues: Improvements to be made by development, including improved quality of the daily stand-up and improving visibility for our project manager
by having several set pieces of detail she requires daily in order to give her complete visibility on the sprint.
by having several set pieces of detail she requires daily in order to give her complete visibility on the sprint. These are only some of the points raised but out of this we had 4-6 points to highlight to the business and a few issues which we can make immediate gains on by applying them to next the next sprint.
Activity 4 | Team Radar: (10min)
This worked well, having four main topics and letting each team member give them a score. Afterword’s the radar graph confirmed our findings and data gathered from the last two tasks, highlighting issues with the business and improvements in the Knowledge sharing and team communications.
Conclusion: This didn't go so well, I didn't really get enough feedback on the retro but after 1h 45mins of good strong conversion it’s understandable. It’s a really good idea but last thing on a Friday afternoon after an intense two week sprint it’s not always possible and suitable, I'm sure people will let me know Monday what they did and didn't like.
Overall I thought the retrospective went well, and even though we performed a much more "agile retrospective" I believe it’s not always the activities you perform; it’s the process of reflection and discussion which is the key point to any retrospective. Getting things of your chest and letting the group understand problems means the true self motivating and self organising attributes of an agile team can really take hold and flourish.
and Agile, and to break the cycle I've been reading 
" so tried adding things on my feature list which can be easily covered and applied from the book, preferences are a ideal point to start applying things I've read/learnt. This should hopefully lead to a large array of customizable functionality within the app.
