jackMilunsky's blog
Introduction
If you're not already a member of the Scrum development group on Yahoo, you really should join. There's a fortune of information changing hands and you can learn so much from the interactions. Just recently there was a huge debate on the topic of technical stories.
The question
The underlying question the team debated was should technical stories appear on the backlog.
Bookmark/Search this post with:
Introduction
I may have blogged about this previously. I have written so many blogs, I can't recall any more. However questions regarding Sprint length surface on the forums regularly.
As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context - this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.
The Context
A team of 5 members currently working with 10-day sprints. They haven't managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.
Bookmark/Search this post with:
Introduction
Based on a recent post on yahoo forums, seems like there may still be confusion out there as to what the differences are between these two roles. Questions like, is there overlap? can the Product Manager take on the responsibilities of the Product Owner? what are the specific requirements for either role? pop up all the time.
There was a really good discussion on the Scrum Development Yahoo group on this topic and some really good points were made. So I'll try to distill this for you here and of course put my own twist on this.
Bookmark/Search this post with:
Introduction
I blogged about this some time ago and then posted the blog on various agile forums to judge peoples responses.
Most of the responses were well reasoned, however, one of the responses I received shocked me somewhat and so I feel that it's worth blogging about this particular situation once more.
The response I received was "You're not serious you're going to ignore the PO" and "You can't be a slave to the process"
In all fairness, there are many situations under which the need to switch stories arise. And the specifics were not really provided. For example:
Bookmark/Search this post with:
Introduction
Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.
So how do we make sense of this all?
My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.
Bookmark/Search this post with:
Introduction
When one looks at all the wastes, defects has to be the most obvious one. The cost and repercussions of finding defects varies depending on where in the cycle they're found. Defects found early on in the development life-cycle are way less costly to resolve than defects found later on in the cycle; the most expensive being when applications are already in-production.
Additionally, depending on when the defects are found, defects can and do trigger other wastes like task switching, relearning etc.
Defects can be very costly for an organization. So the trick with defects is that you need to 1) Prevent them from happening in the first place and 2) Find and fix them as early in the development life-cycle as possible.
So what can you do to prevent them from happening in the first place?
Bookmark/Search this post with:
Introduction
Interestingly, this weeks blog covers the 6th waste - Delays - as identified in Lean. How appropriate after the long delay since my last blog post on Task Switching. Herein lies an example of what Delays in software development can cause. Delays introduce discontinuity and trigger additional wastes already covered like Relearning. It's important in any process, including software, to have continuity. This reduces cycle time and minimizes other wastes like Relearning, Task Switching etc.
Focus on the end-to-end process, not individuals
It's important to identify Delays early on and try to rectify them as soon as possible in order to maximize team productivity. It's interesting... I have been reading many interesting threads on the Agile forums lately about measuring developer productivity, team productivity etc. Managers/executives have us focus our efforts and attention on individuals instead of looking at the end-to-end process to find the real issues that address productivity and enhance team effectiveness.
Bookmark/Search this post with:
Introduction
Previous posts on software development wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features , Extra Processing and Transportation
I must apologize to you all for the lag in this series. But being August, I was away on vacation. Interestingly, getting back is hard. You have to get back into the swing of things again to get up to maximum productivity. There's quite a bit of re-acquainting and relearning so there's waste for sure. However, I do feel I have more energy now since I am back so perhaps the waste is negated over time.
Motion - Task Switching
Waste #5 in manufacturing is defined as Motion. And motion can be compared to "task switching" in Software Development - as defined by the thought leaders applying Lean thinking to software development.
Bookmark/Search this post with:
Introduction
Previous posts on the first 3 wastes can be found here:
In-Process Inventory/Partially done work ,
Over Production/Extra Features and
Extra Processing
It's both interesting for me on the one hand, yet puzzling for me as to what makes a blog popular or not. The first article I wrote on this topic had close to 5000 reads as compared with only 1000 for the last blog post. I figured that based on the response to the first post, folks would be real keen to understand the rest of the 7 wastes in software development. Never the less, I am committed to continuing with the series. Hopefully there are still some of you out there who can benefit from it all.
Bookmark/Search this post with:
Introduction
Waste is a killer in any organization. But if you don't know what to look for then you're probably not going to be able to find waste and minimize it or eradicate it. This series primarily deals with explicitly defining the 7 wastes in software development so that you can start thinking about how this may affect your ability to remain as productive as you can be. This can make a significant difference to your company's bottom line.
As reference, the first two wastes can be found in my previous blog posts here: In-Process Inventory/Partially done work and Over Production/Extra Features.
#3 - Extra processing
Extra processing in Manufacturing is the 3rd waste and this can be equated to Relearning or Rework in Software development. The time we spend relearning things we once knew or having to rework the same feature due to poor code quality can be significant in many organizations, ergo, it's important to be mindful of this. It's probably useful to list examples that would cause extra processing in software development
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle
