Have you heard someone saying “I tried scrum and it didn’t work. Scrum is not working at all!” I heard that many times. It is difficult to admire that it was not the methodology fault, it was your fault that everything failed. The big challenge is that there is no out of a box solution, which suits anyone. You need to go through all the way from the learning to mastery, face a lot of difficulties, overcome them, master the copying and them move to adopting the process for you – changing and improving it. So let’t discuss the problems PM can face while adopting new methodology (you know what I talking about ^_^) All these promlems are from my and my colleagues experience.
We vs they: agile testing
We talk a lot about developers in agile processes but sometimes almost forget about testers. They are usually rather calm and silent people, so they pass through all the project launch meetings and then come to me to ask the important question “Agile is great…But what should I do with my testing activities? What is the role of QA in agile processes?”
As usual, I start my answer with “Folk, it really depends… Let’s see what we might do this time”. So, I will try to describe what we tried and how we failed/succeeded.
Offshore Agile – when your PO is far away
I am sure this scenario will sound so familiar to you. You have a great agile team and great PO overseas. But he can’t devote much time to the distributed team. Yes, you asked him and he tried. But failed – he can’t spent so much time on discussing these user stories. The team starts suffering from the lack of understanding. The user stories are not ready for the development – they are not analyzed and communicated properly. If you ever solved the same issue – let’s continue discussion in the post.
The truth kills me: Half of the features will never be used
The budgeting syndrome is usually connected with the line manager day-to-day life, but PMs seem to have their own unique mutation of it. How the PM budgets the project usually(of course, we all have t&m projects with no fixed cost, but the budget is always there)? You have a great team that estimated everything, but the person who presents the budget is a PM. Here is the point where many of us come to the dark side…
Continue reading The truth kills me: Half of the features will never be used
Where is my city? – Lego scrum simulation
I really love games, that is why I am trying to use them in my work life too. When it comes to the serious questions – adopting new processed framework or show the team why it is great to work in a team – I prefer to use games too. It is fun, it is easy and very engaging. When I came across lego scrum simulation by Alexey Krivitsky, I thought – “Bingo! That is what I need.” In addition – I really wanted to buy some lego and could not find any excuse to do that…So it was my chance.
How to perform great demo
Are you as frustrated when you have to perform a demo to the client as me? Hope, I am not alone) I think, that the sprint demo is one of the most important meetings in the scrum process. It is the time to show our work to the product owner and make our progress transparent. For the team it is very important to celebrate their achievements and see what that achieved. Also it is a chance to receive valuable feedback.
Estimation is the core activity in Agile process. So making it faster and more accurate is the goal of every team. If we also can make it fun – great!
No doubt it is the one of the hardest thing – define, when your product will be shipped. So, taking into consideration all uncertainty of the estimation, planning poker proved to be the simple, but powerful estimation tool for the agile team. It was first described by James Grenning in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning.
Story Mapping: How we do it
As the every development team we have to survive the big stress in the beginning of the project: our clients usually have a lot of ideas, requirements and push us to give them the estimations ASAP) Once we tried story mapping as the requirements gathering tool and sticked to it for a long time. Story mapping appeared to be a great thing when you want to understand what your system is intended to do.
Prioritized backlog helps a lot, when you want to know what to do next, but it is not the best choice, when you want to think about the whole system. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog. Also it is a great tool for planning releases.