For the past five years I have considered myself to be a Agile SCRUM enthusiast. However, recently I have started to doubt the process in terms of it working effectively. Some of the key issues I have are:
- The planning overhead which comes around every iteration
- The reliance on promoting productivity by limiting the time available during an iteration
- A successful iteration relies on accurate estimation and that is always accurate right!?
- Retrospectives are negative by nature
Of course there are many benefits that SCRUM brings to the table, such as the focus on iterative development, continued customer engagement and measurable performance (that one is the manager in me).
Recently I have been researching Kanban as an alternative option to SCRUM. Kanban literally throws sprints out of the window – not to mention those long planning meetings. This methodology focuses on continuous flow – driving productivity by limiting the number of work items in progress at any one time. The focus is on completing what you start. One phrase these past few days which has stuck with me which I think I read on the Kanbanize blog was – Stop starting and start finishing. I believe this sums up Kanban’s essence perfectly.
Or perhaps Connection Error would be a more apt name? In terms of what I have played so far – I actually really like the game. I have found it quite easy to get into and most enjoyable when racing. The visuals are immense – but that was a given surely. In terms of the actual game, I would of really have liked to seen the dynamic weather and replays even more so.
So I’ve recently started to work on a personal project. Now due to time available, motivation, PS4 etc. it is impossible to say if this project will “make it” lets say. But for now I will assume it will (Lets at least start positive!). The aim of the project is to deliver an Agile Management System – something a bit like one that starts with J and ends in A. However, this system will work exactly in the way I think it should – and why? Because I’m going to write it!
Here are some do’s and don’ts when it comes to reviewing peer code.
- Find things which are GOOD!
- Do NOT just look for things that are bad
- Look for common repeated issues
- Do not review a lot of code at once
- Remember no code is perfect – so implementations can be subjective
- Do NOT get emotional!
- Do not focus on BLAME
- Do not focus on how YOU would have done it
- Do not attempt to redesign the solution
- Try to avoid looking for one-off minor issues
My final post in this area brings me to another point which is often a popular debate subject. Now it is important to remember that every team is different and every teams interpretation or implementation if Agile will differ. The key fact to remember is that it is important to find a implementation that works for your team – as at the end of the day the key point is you want to have a team that is efficient, effective at meeting delivery targets and ideally happy!
Stories should be prioritised so that requirements that add the most value can be delivered first. The MoSCoW principle is a popular format for defining priority and one I like to use get a quick overall feeling on where each stories ranks against each other:
- Must – Critical
- Could – Important
- Would – Nice to have
- Won’t – Something to evaluate for future releases
I’ve tried to describe below some key points which help keep stories relevant and meaningful. It is not always easy to write good stories, but practice does indeed help. When you and your team have a agreed format or set of principles of writing stories, I always find it helpful if they are visible somewhere as an aid to ensure keep reviewing your stories – and that you are sticking to the principles you have agreed!
User stories are a awesome method for expressing stakeholder requirements, for example those of the product owner. They enable requirements to be described in simple and understandable dialogue. When a customer or product owner initiates a project – or has desire to build some new application feature, there are various elements that need to be examined…
I always find myself challenging my own views on Agile and what is the best approach. I guess I am not convinced there is one best solution (well not that I have yet seen), but many good ideas (or aspects) on how to use Agile and some other generally really bad ideas on what not to do. For me it is all about finding the right fit and selecting those good ideas that work for your team. That fit will almost certainly depend on the team and organisation – hence very few situations/teams are identical.
Thus using Agile effectively isn’t always easy… You may receive challenges and friction from an organisation that does not understand (or care to), to resistance from your own team if the what or how you are trying to implement – if doesn’t fit with them. It is important that any adoption remains flexible as every organisation, set of team members and customers will be different. As will the varying pressures to deliver and perform that each team will encounter. Finding the right formula which will be unique to your team is the key. My own perspectives on how to implement Agile has changed and grown with each new experience and with different teams I have been a part of.