Blogs
Here is the top writing that caught my attention this week.
You might like having a look at the previous link packs as well.
If you happen to encounter another interesting content published since last Friday, please, post links in the comments.
»
Use Risk Management to Make Solid Commitments How to be able to commit to the long term schedule while being explicit about the amount of risk. And
the real-life example »
Notes from a Tool User: Agile 2008 Post Roundup A great collection of links to posts about the conference Agile 2008
»
thekua.com@work " The world mocks too much Advice on what should and what should not be mocked
»
Google Testing Blog: To "new" or not to "new"... Google on what factories are good for and what they are not good for
A few weeks ago I had the opportunity to read a book by Hal Edward Runkel called Scream Free Parenting. The title is a little misleading because the book is not really about screaming and the lessons Hal teaches go beyond just parenting. The book is about controlling your anxiety so you can build healthy relationships.
The key idea of the book is that anxiety is at the root of much our conflict. Think about it… we want better behavior from our kids, we are not getting it, and not getting that desired behavior stresses us out. When we yell at our children, we are really saying "I want to be calm, you are not allowing me to be calm, I demand you change your behavior so I can be calm".
I was just reading an excellent book by Josh Bloch, namely "Effective Java, Second Edition" and I was on the optimization subject when it happened. It was funny coincidence but I think it was just a sign for me to write this post.
It doesn't relate to the Agility in any way but it relates to the quality of software so it should be definitely published here. And it all started very innocently - from publishing blog post with the solution to some annoying problem.
In this post I will tell you how easily you can fall into really dangerous and ugly development problems starting optimizing your software too early. I hope you will like the story.
Any project plan is a mixture of what the product owner wants and what the team can actually deliver. The product owner naturally wants more than the team can deliver, so s/he has to prioritize in order to get something useful in the desired timeframe.
Once you have a prioritized product backlog, you have the prerequisites for calling the first Sprint Planning Meeting. How do you convert an unordered list of features into a prioritized product backlog which you can give the team to implement? What should you do first?
I’m not sure that there is a correct answer to this question. It will depend on your product, your company and your situation. Let’s take a look at some widely used strategies for prioritizing the product backlog
- Minimum Marketable Feature Set - the first pass to narrow the list of stories
- Business Value First - Focus on High Value Functions
- Bang For the Buck - Go for easy wins
- Technical Risk First - Do the hard things first
- Defer Risk - Do the hard things later (or never)
- Vote - Ask your users
Given the problem (most managers call it a 'challenge') of running many dozens of projects concurrently, with just a small number of people, I've been asked a few times how we organize projects and resources in our company. Well, there's a lot to tell about this subject, and my attention span (as a manager) is rather short. So I'll spread that information over several posts.
Many of our customers have simple, small requests: requirements that take just a couple of days or weeks to fulfill. This means that the organizational complexity (some employees call it 'chaos') is vastly different from other companies, where they have teams of many employees working on just one project, often for many months at a time. But I am sure that lots of people face similar problems (or challenges if you prefer) as we do, working on numerous small projects. So let me tell you what we did...
Welcome to Part 6 of my team's first adventures with Scrum. If you want to start from the beginning, see the table of contents at the bottom of this article. Each part stands alone though so don't worry.
In this part of the series, I'll talk about what we did when we approached what we thought was going to be the end of the project. As it turned out it was only the first deadline that we would miss. Near the first deadline we went off of doing Scrum sprints and planning in favor of fixing bugs as they came up in testing. This cost us a lot of team cohesion and focus. Read on to hear about what led us to missing the deadline, why we went off Scrum and how we got back on the right path. As usual, I hope our story helps illuminate some decisions teams make with the best of intentions that can lead to unforeseen negative consequences.
Here is the top writing that caught my attention this week.
You might like having a look at the previous link packs as well.
If you happen to encounter another interesting content published since last Saturday, please, post links in the comments.
»
Scrum Log Jeff Sutherland: Agile Specification: is it a hoax? or a necessity? Agile and specification aren't the opposite things. Here's how you can build the extensive specification step by step.
»
Scrum Log Jeff Sutherland: Roots of Scrum: Object Technology Did you know that Scrum was designed to support the object oriented software development?
Lance Armstrong won seven consecutive Tour de France races between years 1999 and 2005. Every year there were 21 individual stages and Lance Armstrong won "only" 4 individual stages in 1999, 1 stage in 2000, 4 stages in 2001, 4 stages in 2002, 2 stages in 2003, 6 stages in 2004 and 2 stages in 2005.
As you can see Lance Armstrong was not focused on winning each stage (quite the opposite). He was focused on winning the whole Tour de France - yet he had to keep close to the head of the race. And when you take a look at time differences between him and the second cyclist in the final classification you will be amazed - they were close to couple of minutes (out of 90 hours of total time!) It means that he was focused on winning the whole race - not to be the best and outstanding cyclist (he was not - I know because I watched many of the stages these years).
Speaking with the lean language Lance Armstrong was Optimizing the Whole - and he succeeded seven times winning the most difficult and exhausting cycling race in the World.
In this post I will try to explain "Optimize the Whole" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Once you know who you are building the product for, the next step is to create a list of features which will excite your customers and get them to use and buy one of your products. Which functions should you put into the system, and why? The user story workshop creates the initial product backlog.
This workshop is similar to the last workshop where you identified the users and buyers of your systems. This workshop needs the same people, except that the importance of the development team rises as you get closer to implementation. It is also desirable to have some real users represented. The workshop structure structure is simple:
- Review the format of User Stories and the Kano Model.
- For each Role,
- Identify the main goals
- Identify the functions which that person wants the system to perform to achieve those goals
- Decide on next steps: Homework or Implementation
Some people tell me that "you cannot motivate a person". You can only "remove the impediments that prevent a person from being motivated". Or, in other words, "you can only eliminate demotivation".
Well, I don't agree!
Can you make a person happy? Or can you only eliminate the things that make her unhappy?
Can you make a person laugh? Or can you only eliminate the things that make him cry?
These sound like silly questions. But I have been told a number of times now that trying to motivate people is a bad idea. Yet, I simply could not imagine this to be true, given the fact that it is quite possible to (try to) make people happy, or to (try to) make them laugh.
RSS feed