Hello one and all. Another week in the agile world has passed and brought with it the twenty second edition of “This Week in #Agile”. As ever our PM team have been hunting through the web to find and read your blogs and articles. Here are just some of the articles that we found this week which we would like to share with you, along with some of our take aways and learnings from them.
A question I’ve constantly been asked is why use story points… let’s face it in a lot of cases people equate these to time. Whether it’s 5 points is roughly a day, or a point is roughly an hour, why don’t we use time. As Leon raises there is a notion of value but it is something which is very difficult to qualify or quantify. This is definitely a subject worth taking a deeper dive into.
Although I don’t have kids myself, I’ve often used and written blogs about using Agile processes in other walks of life, even trying to put up . I’m not quite suggesting that getting the kids scrum boards and watching them develop that way is best but it is yet another way that Agile is something that you can use not just in the workplace but also at home.
Team sizing is always an interesting topic. We’ve all heard the adage of “too many chiefs not enough indians” in regards to management levels and also “too many cooks spoil the broth” when it comes to too many people trying to do the same thing.
I’ve seen this happen with projects where too many engineers are involved, where engineers are either underutilised or the codebase becomes convoluted as merge conflicts become a regular occurrence with PRs taking much longer to resolve as rebasing occurs.
So what is the best team size? Most Agile textbooks would say between 3 and 9 people, with 7 being ideal. I can agree with this again from my experience and the size of the project can affect this number. But rather than having one large team, breaking the teams down to more manageable teams (maybe working on different microservices if that approach makes sense) and practising scrum of scrums is a more useful way of managing the project.
Yet another blog from Leon for this week’s edition!!! In the projects I have worked on I have, at various points, switched from Scrum to Kanban. The reasons are varied and sometimes the switch has proved beneficial, other times not. My personal preference is to use Scrum for developing a project, however once it reaches a level of maturity such as an MVP, moving to Kanban has often helped in terms of allowing clients the flexibility to deal with changes suggested by stakeholders and users. This article is a nice way to see the benefits both methodologies can bring to a project.
As shall continue to be the case with this weekly blog on all things Agile and Project Management, if you write a blog or read an article you would like to be included feel free to contact me either via email - [email protected] - or twitter - - and we can try and include it in a future edition!
This week’s image is another by and is related to the values of scrum.
See you next time folks!!