Originally
when I finished University and took my first step in the big wide world of
work, taking on the role of a junior software engineer, we would perform some
form of a retrospective after each release cycle. Thinking of ourselves as
being agile, practising Scrum, amongst other things we would be working on 2
week sprints, releasing to the business at the end of each sprint, morning
stand-ups, planning poker, retrospectives and all the other tools and practices
available to an agile team. This wasn't always the case but when time permitted
and resource allowed, we would get together in a room, usually lead by my boss,
and come up with a list of "What went well?", "What
went wrong?" and "How can we make it better?", voting
on each point, prioritising a list and if we get chance trying to elevate some
of the points noted.
That was
four years ago, I have no doubt that I have changed in those 4 years. Becoming
a more proficient and confident engineer, become more confident with the
business and with others and having changing opinions about the agile movement.
I think it’s worth noting that agile rocks, or what I think agile is all about
rocks and I love the software craftsmanship movement,
probably as I am a true geek at heart, feeling very passionate about the
software I write. I also like to think the craftsmanship movement relates to
myself a little, always striving to produce high quality software which will
add value to my users, always trying to write clean code, always trying to
practice TDD etc. Software Engineering being such a broad subject there are
obviously things which I don't do so well and obviously things which I should
change, this could cover an entire blog post itself so I will miss those bits
out and focus on the question "Are Agile Retrospectives a Must?".
As far as
retrospective go, I haven't been on any courses and defiantly don't have a
certification in it. On the other hand, I have read several books, attempted to
lead several retrospectives and attended a lot. I will put forward my
foundations for asking this questions and my reasoning's behind it.
So
retrospectives are primarily a forum to reflect on the last iterations set of
work and highlight issues or problems people are having. These problems could
relate to any topic e.g. technology, the business, fellow team members, 3rd
parties or maybe just the general feeling for the ongoing project by the
team. Below are some of the good and bad points about Agile Retrospectives:
Good
- Points get raises
- People get issues of their chest
- Issues can be resolved
- Blockers come out
- Team disagreements come to the surface
Bad
- People don’t remember on long projects
- Difficult for people to get involved
- Difficult when people work on different projects
- People take things to personally
- Actually dealing with the issues after, who, how, when?
- Doesn't fit a Kanban approach.
- What if you don't have sprints but are constantly developing and releasing?
Now
obviously there needs to be some sort of forum where team feedback and conflict
resolution can occur and my main point is that with all the good will in the
world having a de-facto agile retrospective doesn't always work? As companies
move to a more continuous and lean approach to software development, sprints go
out the window. You tend to work on projects which may span months, weeks, days or hours but
you’re putting out software daily, easing the impact on the user,
reducing the risk on every release, little and often is the game we play (or
try at least). So how does this practice work with the agile retrospectives I
have read about and practised in myself? It doesn't, when we would release
every 2 weeks without failure it was great, every 2nd Friday afternoon we would
have a retro, trying lots of ideas (usually from here) and usually it was productive.
But even when you have set release cycles likes this I find two weeks can be
long time and things which have caused issues can be missed.
Alternatives
to retrospectives in my mind are purely dependant on how well communication in
your team is. In my opinion a short weekly get together combined with good
daily communication will solve most if not all of your problems. Spread the
knowledge, get some sort of forum in place like campfire,
and post issues you’re having to the whole team. Get a wiki so complex process
can be documented (briefly); make sure everyone in the team is in the know.
Simply by sharing as much knowledge as you can you will find that tension
drops, people are more confident in taking on any task, code ownership is
spread amongst the team and people are not solely responsible. Business issues
which you are having report them up the chain but ensure everyone is aware you’re
having issues and then they won’t be so frustrated if they hit them to.
Internal team issues can be brought up in a short weekly meeting, put the issue
on the table, let everyone know and see what people say. People should already
know if things haven't gone well as they have heard it, read it on the forum,
or witnessed it during the week.
Now the
above approach won’t always fit your team and I may be completely mistaken as
to what I think best practice is and what is the best solution to solving
conflict and issues which are preventing software from being delivered. What I
do feel strongly is that once you have moved away from a scrum based development
style to a more Kanban based development style, dropping the set release cycles
and moving to a more on demand approach, the usefulness of a set retrospective won’t
fit your need. You can obviously elbow the practice into your process but
thinking again about this approach you may find taking a different angle on the
subject you may find it will yield better results.
James
really have} withdrawn cash in final few|the previous few|the previous couple of} months; that's pretty good in order that it can be be} carried out. Firstly, I played a web-based popular slot machine after joining a popular bingo hall and on-line company. And low and behold, after depositing a modest sum had a just about quick win followed by successive wins giving me a 점보카지노 substantial reward for my funding.
ReplyDelete