News

Yes I’ve been slack but now I’m back!


Posted by Ilan on August 14, 2013
I'm Ilan Goldstein and I'm a director here at AxisAgile. I'm a Certified Scrum Trainer and the author of Scrum Shortcuts Without Cutting Corners. Find out more about me or get in contact with me by using the social buttons. I also respond to comments below.

I’m back! I know it has been way too long between drinks but better late then never I say! So where in the blogosphere have I been you ask? Well there are no doubt super-freaks out there who are able to write a book, start and run a business, navigate their first round of parenthood (with a cute impediment that doesn’t subscribe to the concept of sleep) AND maintain an active blog but sadly, I’m not one of them. Something had to give and that ‘something’ was the blog . I must apologise for this but hey, I managed to juggle three out of those four balls successfully (I think) which isn’t too bad!

On a brighter note, the great news is that the book is done (as in done done!) and blogging will now continue!

There will be more information about the book in subsequent posts but in a nutshell, it is a major extension of the original Scrum Shortcuts Without Cutting Corners blog (and very unoriginally uses the same name), is published by Pearson (under the Addison-Wesley brand) and sits proudly as part of the fantastic Mike Cohn Signature Series (a huge honour).

For those that had been following the original blog there are a few things to note:

  1. For disambiguation purposes, the www.scrumshortcuts.com domain will now be dedicated to the book rather than the blog. It will contain information about the book and a selection of print-ready sample chapters including all artwork.
  2. The original blog articles have now been moved to www.axisagile.com.au/blog . These blog articles have been updated with supplementary content from the book to avoid confusion and (hopefully) add further value.
  3. Future blog posts (including this one of course) will also be located at www.axisagile.com.au/blog
  4. If you are a subscriber to the original blog, I have taken the liberty of maintaining the subscription for the new version. If you have any issues with this please feel free to unsubscribe although I will certainly miss you ☹

I hope that this transition makes sense but if not, feel free to send me a note and I’ll be happy to elaborate further on what’s happening.

Again, thanks for your immense patience but I’m sure you understand that sometimes you actually need to practice what you preach when it comes to context-switching and working sustainably ☺

I’m excited to be back and hope you’ll continue the journey with me!

If you liked this article, you can:
Subscribe to this RSS feed!

  • Emile Veliyev

    Shalom Ilan,
    thanks for the book of tips, very useful and in most cases reassuring that you are on the right path when you find others thinking the same way.
    I would like to ask you though about one issue that I had encountered during my SCRUM Master duties and honestly don’t have a confident solution yet.
    The issue is more relevant for the enterprise level organizations that are on transition to Agile/SCRUM and those who would like to think they are Agile just because they use multiple iterations in their SDLC. These types of organizations with very strong Vertical Structures of the resources and very strong habits in the way they monitor and control projects create the so called Hybrid solutions that in most cases block most core benefits of the Agile approach leaving the surface feeling of the Agile cause they follow iterative methodologies imho.

    So one of the issues I faced was with blocked unexpectedly Stories in Sprint and how to deal with them.

    I’m talking of the blocks/impediments that can’t be resolved during the Sprint time effectively .
    I agree that in general having constantly such cases in each sprint is the indication of bad sprint planning and risk management like when the team identifies the story to be ready for Sprint while it has a lot of external dependencies with the very big risks not to be met.
    It also an indication of bad estimating and prep for the sprint as well as indication that you don’t have dedicated resources in the SRUM team that it’s state of maturity requires it.

    I also think that such cases are the Red light that the improvements have to be made to fight the root cause.

    Though due to organizational immaturity and other external dependencies no matter what you think or do these improvements are long term issue and can’t be resolved immediately, making the project constantly suffer from these factors that cause constant blocks/impediments that you have to live with regardless to the fact that you want and know that the root causes should be resolved.

    This almost 90 percent the case during the transition period when both teams and upper level management and stakeholders have a lot of misconceptions of what Agile means and why it creates the benefits claimed.

    So this is situation you have constant blocks and impediments that you can’t resolve short term without changing org structure first, which leads to constantly having Stories that do not meet the DoD criteria.

    The question what to do with them?

    The answer is straight forward return them to PBL and re-prioritize and reevaluate their readiness for future Sprints.

    But in that case they impact the velocity of both current and future sprints.
    Say we completed 90% of tasks for the Story and it blocked.
    These 90% of effort is removed from current velocity and added to future which creates spikes and drops in velocity that look ugly on the report.
    Your velocity trend instead of having the predictable trend becomes sporadic and unpredictable and the stakeholders feel that the project is not under control . The Stakeholders do not care that the org structure and improper immature team organization causes that, they want to feel safe that the project is able to achieve the goal.

    So from one hand you want to be transparent and not to hide issues on the other hand you want your stakeholders been satisfied.
    One person recommended to split these stories and claim 90% of story points in the current sprint while returning to PBL the 10% Story for future.

    That will smooth the Velocity graph for sure but the way i see it violates the core agile principle cause non of these Split Stories have Business Value and you claim it.

    The Story claim is all or nothing assuming that there is no way to split it so that parts have Business Value as well.

    But we also have to be adaptive and adapt to this Hostile environment as well.

    My thoughts are to either to switch to SCRUM-Kanban hybrid with never ending SPRINT and continuous workflow , cause in that case if something blocked you continue with to next one till this block is released. The velocity is stable. But it takes a lot to convince the upper management that your are not ready for iterative SPRINTS.

    Or to change the format of calculating velocity from Done User Stories to Completed Story points in sprint but still returning the full Story to the Backlog without splitting it.

    What are you thoughts on this?

Sign up to receive our eNewsletter

testimonials

SOME OF OUR GREAT CLIENTS

Send this to friend